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Preface 


This  report  is  based  on  an  analysis  of  Department  of  Defense  (DoD),  Capacity  Management  Function 
activities,  associated  with  performance  measurement  and  capacity  planning  processes  of  Information 
Processing  Centers  (IPCs).  The  modeling  results  address  all  aspects  of  Capacity  Management,  and 
apply  to  all  systems  and  components  of  the  Defense  Information  Infrastructure.  This  final  report  is  a 
composite  of  all  prior  working  papers,  and  replaces  any  previous  editions. 

Because  the  modeling  results  of  this  report  are  based  on  a  structured  and  integrated  analytical  process, 
interpreting  the  results  out  of  context  (as  provided  by  the  defined  terminology)  and  without  respective 
qualifying  conditions,  may  lead  to  erroneous  conclusions.  Questions  related  to  this  report  should  be 
addressed  to  The  Defense  Information  Systems  Agency,  Joint  Interoperability  &  Engineering 
Organization,  Center  for  Information  Management,  Infrastructure  Program  Directorate 
(DISA/JIEO/CIM/XI).  701  South  Court  House  Road,  Arlington,  VA  22204-2199,  Attention:  Mr. 
Charles  A.  Archer,  Sr.,  Project  Manager  [(703)  285-5323). 

To  ensure  the  widest  dissemination,  current  planning  calls  for  this  document  to  be  made  available 
through  the  Defense  Technology  Information  Center. 
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Section  1 

Executive  Summary 


This  rqx)rt  provides  the  foundation  and  structure  for  development  of  policy  for  a  Eiepartment  of  Defense 
(DoD),  Information  Systems,  Capacity  Management  (CM)  Function.  The  objective  in  this  workshop  was  to 
provide  a  DoD-wide  standard  framework  for  conducting  performance  measurement  and  capacity  planning 
activities  across  all  Defense  Information  Infrastructure  (DII),  Information  Systems  (IS),  and  configurations 
(i.e.,  mainffame/host  computers,  communication  systems,  and  networks).  In  many  ways,  the  activities 
described  in  this  document  are  similar  to  collective  CM  processes  used  in  the  DoD  today,  primarily  for 
mainframe  environments.  However,  the  processes  modeled  in  this  report  were  constructed  as  the  "best 
practices”  of  all  approaches  to  Capacity  Management,  and  have  been  extended  to  include  all  DoD 
communication  and  network  systems. 

Further,  the  Capacity  Management  processes  defined  in  this  report  are  intended  for  use  in  all  DoD  IS 
environments,  such  as  Megacenters,  base-level  military  installations,  and  Central  Design  Activities  (CDAs)  in 
all  fixed,  mobile,  and  remote  locations. 

The  DoD  Information  Systems  environment  to  which  this  CM  Function  will  be  applied  is  represented  by  16 
(planned)  Megacenters  currently  made  up  of  194  Data  Centers;  over  SOO  mainframes;  650,000  PCs;  and 
10,0C)0  Local  Area  Networks,  with  their  associated  communications  media,  modes,  and  interfaces.  Most  of 
these  systems  currently  serve  approximately  1,700  military  and  civilian  DoD  installations,  many  of  which 
have  requirements  for  mobile  and  overseas  computer  systems  capabilities  in  multi-force  and  multi-national 
interoperable  environments,  and  quick-response  computing  capabilities  to  meet  wartime  mission  requirements. 

This  document  was  prepared  during  the  time-period  from  July  19,  1993  to  October  29,  1993,  by  a  workshop 
team  composed  of  DoD  Capacity  Managers,  and  subjea  matter  experts.  The  models  presented  herein  were 
developed  using  the  analytical  Functional  Process  Improvement  Methodology,  Integrated  Definition  Language 
(IDEF)  process  and  modeling  techniques,  as  prescribed  by  DoD  8020. 1-M. 

The  workshop  results  presented  in  this  document  display  an  innovative  and  visionary  approach  to  managing 
critical  performance  planning  and  cost  aspects  of  Information  Systems  operations  across  the  DoD.  All  of 
these  models  have  been  constructed  at  a  level  of  detail  sufficient  to  support  DASD  (IM)  objectives  for 
development  of  DoD-wide  policy  and  standards  for  this  Capacity  Management  function.  Ute  following 
summary  presents  the  most  significant  Capacity  Management  issues  and  recommendations  presented  in  this 
document. 

Capacity  Management  issues  include: 

•  The  edacity  Management  Function  is  an  integral  element  of  Information  Systems  Management. 

If  we  are  to  understand  system  performance  issues  affecting  our  current  and  emerging  (e.g.. 
Megacenter)  environments,  we  must  have  a  standard  approach  for  managing  systems  performance, 
evaluating  capacity  requirements,  ensuring  standard  data  collection  procedures,  and  standard  reporting 
methods.  The  CM  processes  described  herein  provide  a  structure  to  enable  standard  CM  practices 
across  the  DoD. 
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•  The  cost  of  Information  Systems  in  the  E)oD  must  be  better  managed  and  controlled  if  we  are  to 
achieve  the  goals  of  systems  consolidation  and  cost-reduction.  This  CM  Function  will  enable  better 
performance  management  and  capacitv  olanning  of  all  DII  Information  Systems.  This,  in  turn,  will 
reveal  opportunities  for  system  perfon.  once  cost-savings,  and  improved  cost  accounting  (e.g.,  fee-for- 
service)  capabilities  through  more  efficient  CM  processes  and  effective  performance  management, 
cost-effectiveness,  and  resource  utilization  of  DoD  Information  Systems. 

•  With  the  move  toward  open  systems  and  distributed  client/server  architectures,  we  must  merge 
our  existing  legacy  mainfimne/host  computer  systems  and  network  environments  into  interoperable 
configurations.  This  CM  Function  will  provide  a  standard  process  for  the  performance  measurement 
and  capacity  planning  of  all  DII  Information  Systems,  regardless  of  configuration  or  design. 

•  A  Capacity  Management  baseline  modeling  approach  is  prescribed  for  all  DII  Information  Systems. 
This  standard  model  development  activity  will  ensure  that  all  DII  configurations  will  (1)  be  modeled 
in  a  consistent  maimer,  and  (2)  that  information  exchange  between  various  system  configurations  will 
provide  interoperable  and  similar  data  modeling  and  reporting  information. 

•  The  lifecycle  development  of  system  designs,  communication  systems,  network  topologies,  application 
software,  etc.,  must  involve  all  aspects  of  the  CM  Function  to  ensure  that  performance  implications 
and  opacity  issues  are  addressed  in  a  timely  maimer  prior  to  implementation. 

Recommendations  and  Improvement  Opportunities  Include: 

•  Prepare  a  C3I  policy  directive  for  promulgation  of  this  CM  Function  across  all  DoD  organizations  to 
ensure  a  comprehensive  and  standard  CM  capability  and  implementation  is  achieved. 

•  Ensure  centralized  control  and  distributed  execution  of  the  CM  Function  throughout  the  DoD. 

•  Establish  a  CM  Steering  Group  for  coordination  of  CM  issues  affecting  all  DII  Information  Systems 
environments. 

•  Establish  a  Configuration  Control  Board  (CCB)  to  provide  policy  and  oversight  for  changes  to  all 
Dn/IS  configurations. 

•  Define  CM  as  a  major  organizational  element  to  ensure  effective  implementation  and  management  of 
the  CM  Function  in  all  information  systems  organizations  across  the  E>oD. 

•  Ensure  that  the  CM  function  is  included  in  all  Information  Systems  planning  processes  including 
development  of  short-  and  long-range  (Service,  Agency,  and  DoD)  plans,  life-cycle  design  processes, 
user  requirements,  system  enhancements,  CDA/user  performance  objectives,  etc. 

It  is  the  opinion  of  the  Workshop  Team  that  the  implementation  of  this  CM  Function  is  paramount  to  the 
effective  establishment  and  operation  of  the  emerging  DoD  Megacenter  environment.  Further,  the  CM 
Function  will  also  enable  standard  and  compatible  (e.g.,  with  Megacenters,  IPCs,  CDAs,  etc.)  performance 
measurement  and  capacity  planning  activities.  Without  a  standard  process  for  managing  and  reporting  the 
performance  and  capacity  of  all  DoD  Information  Systems,  effective  management,  cost-containment  of  IS 
resources,  and  long-range  planning  will  not  be  possible. 
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A  final  workshop  report  and  briefing  will  be  presented  to  the  Deputy  Assistant  Secretary  of  Defense  for 
Information  Management  (DASD/IM)  C3I,  who  sponsored  this  project.  The  Defense  Information  Services 
Organization  (DISO),  in  the  Defense  Information  Systems  Agency  (DISA),  has  been  a  hill  time  participant  in 
the  development  of  this  Capacity  Management  Function.  DISO  is  preparing  to  use  the  results  of  this  effort  in 
their  planning  for  Capacity  Management  in  the  new  Megacenter  environment. 

Upon  completion  of  this  workshop  effort,  DISA/JIEO/CIM  (Joint  Interoperability  &  Engineering 
Organization/Center  for  Information  Management),  at  CSI's  direction,  will  assist  DASD/IM  C3I,  DISO,  and 
DISN  in  their  efforts  to  implement  this  CM  Function  across  the  DoD. 
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Section  2 

Introduction  and  Project  Plan 


Introduction 

In  May  1993,  the  Deputy  Assistant  Secretary  of  Defense  (DASD)  for  Information  Systems  GS)  -  [now 
DASD  for  Information  Management  (IM)].  C3I,  commissioned  a  workshop  to  examine  and  in^rove 
activities  associated  with  the  DoD  Information  Systems  Caf>acity  Management  (CM)  Functional 
Activity,  and  to  broaden  the  scope  of  the  Opacity  Management  Function  by  designing  a  DoD-wide 
CM  process  for  all  Information  Systems,  including  Communication  and  Networks.  This  initiative 
represents  a  major  step  toward  effective  management  of  the  evolving  consolidation  of  all  Department 
of  Defense  (DoD)  Information  Systems,  as  directed  by  Defense  Management  Report  Decision 
(DMRD)  918  and  previous  DMRDs. 

To  develop  the  Ciy)acity  Management  Function,  the  workshop  team  used  methods  and  techniques 
iq)proved  by  the  Director  of  Defense  Information  (DDl);  Command,  Control,  Communications  and 
Intelligence  (C3I);  as  defined  under  the  Corporate  Information  Management  (CIM)  Program. 
Specifically,  the  workshop  team  conducted  its  efforts  using  IDEF  techniques  according  to  the 
Functional  Process  In4)rovement  Program  (FPIP)  for  functional  managers,  as  directed  by  DoD  manual 
8020. 1-M,  dated  1  Oaober  1992.  (Workshop  participants  are  Usted  in  this  section.) 

Senior  level  guidance  for  this  initiative  was  provided  by  DASD  (IM)  C3I;  DASD  Plans  &  Resources 
(P&R),  ITR/C3I;  and  the  DISA/JIEO/CIM/XI,  Infrastructure  Program  Director.  Project  management 
and  direction  was  provided  by  Mr.  Charles  Archer,  Sr.,  DISA/HEO/CIM/XH. 

The  DoD  is  currently  involved  in  a  computer  systems  migration  and  automation  effort  on  two  fronts: 
(1)  moving  from  an  installed  base  of  sq)arate  and/or  networked  base-level  computer  systems  on  DoD 
military  and  civilian  installations  to  a  Megacenter/Mainframe  environment;  and  (2)  moving  from 
primarily  vendor  specific  systems  (e.g.,  IBM,  UNISYS,  etc.)  to  "open  systems”  and  interoperable 
environments.  The  driving  force  in  this  effort  is  DMRD  918,  and  previous  DMRDs,  that  direct 
consolidation  of  data  centers  into  consolidated  groups  (i.e..  Megacenters)  of  Information  System  (IS) 
configurations  designed  to  produce  greater  processing  efficiencies  and  cost  savings. 

The  successful  implementation  of  C3I  policy  for  this  C^adty  Management  Function,  will  also 
support  current  direction  by  the  Deputy  Secretary  of  Defense  to  accelerate  in^lementation  of 
migration  systems  and  related  process  improvement  activities  toward  accomplishment  of  a  new 
Defense  Information  Infrastructure  (DII).  A  gr^hic  dq)iction  of  the  DII  is  shown  in  ^)pendix  G. 

Background 

As  a  result  of  discussions  in  March  1993,  between  DASD  GS)  C3I;  DASD  (P&R),  rrR/C3I; 
DISA/JIEO/CIM  Infrastructure  Program  Directorate  (XI),  and  DISA/DITSO-GAT  [now  DISO-UAT], 
an  initiative  was  begun  to  perform  an  IDEF/FPl  project  for  the  C^acity  Management  Function. 

An  executive  session  briefing  was  convened  on  May  18,  1993,  by  DASD  GS)  to  discuss  initiation  of 
this  Business  Process  Improvement  (BPI)  workshop  series.  This  briefing  provided  the  background, 
and  subsequent  clarification,  of  issues  to  be  addressed  for  the  CM  Function,  as  described  in 
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subsequent  memoranda  from  DASD  (IS)  dated  May  11.  and  June  11.  1993,  SUBJECT:  Department  of 
Defense  Information  Systems  CM  Function. 

Subsequently,  a  five-piiase  project  was  designed  to  establish  (1)  a  Baseline  AS-IS  Activity  Model;  (2) 
an  IDEF  Training  Class;  (3)  a  Dll-wide  TO-BE  (i.e.,  future)  Activity  Model  and 
Megacenter/Mainframe  Entity  Relationship  Data  Models;  (4)  Dll-wi^  TO-BE  Networks  and 
Communications  Activity  Templates  and  Entity  Relationship  Data  Models;  and  (S)  a  final  report 
describing  the  modeling  results,  interoperability  of  models,  definitions  of  CM  terminology,  and 
narratives  discussing  the  use  of  the  CM  Function  models. 

The  Purpose  of  Capacity  Management 

edacity  Management  (CM)  is  an  umbrella  title  that  provides  for  the  management  of  all  activities  of 
CM.  CM  includes;  performance  measurement,  capacity  planning,  and  prediction  modeling  of 
computer  systems,  communications  systems,  and  networks. 

The  primary  goal  of  Capacity  Management  is  to  ensure  sufficient  capacity  exists,  and  is  available,  to 
meet  the  service-level  objectives  of  the  user  community  at  any  time.  The  capability  to  satisfy  usci 
requirements,  and  maintain  reserve  capacity  for  peak  or  unexpected  workloads,  added  workstations,  or 
higher  traffic  loads  on  a  LAN,  etc.,  is  the  business  of  Capacity  Management. 

The  question  of  why  we  need  opacity  management  is  one  that  is  easily  answered  with  an  illustration. 
Capacity  Management  originated  in  the  'mainframe''  arena,  but  is  now  being  applied  to  "open 
systems"  distributed  architecture  (e.g.,  client/server)  systems,  and  communications  areas.  In  the 
mainframe  world,  monitoring  systems  usage  and  workloads  processed,  as  well  as,  predicting  how 
future  workloads  would  impact  system  operations  b«:ame  necessary  if  these  systems  were  to  meet  user 
requirements. 

Since  the  advent  of  distributed  systems,  the  need  for  performance  measurements  and  capacity  planning 
has  become  more  evident  as  we  try  to  maintain  service-levels  and  response-times  that  were  plaimed 
prior  to  building  a  network,  and  ensure  sufficient  communications  bandwidth  (c:q>acity)  is  available  to 
transmit  data  across  networks. 

We  have  found  that,  not  only  do  we  not  know  enough  about  the  day-to-day  performance 
characteristics  of  networks  we  have  established,  but  that  tools  and  capabilities  to  perform  network 
measurements  are  not  readily  available;  especially  since  interoperable  networks  (similar  vendor 
configurations  and  protocols)  are  not  commonplace. 

Thus,  we  have  the  dilemma  of  trying  to  manage  performance  and  capacity  in  PC-to-Mainframe 
configurations  that  do  not  readily  lend  themselves  to  such  activities.  Further,  these  configurations  are 
evolving  into  Megacenters,  consolidated  LANs/WANs,  etc.,  and  the  future  performance  of  such 
consolidations  is  not  readily  apparent. 

Although  the  right  tools,  sizing,  and  protocol  interoperability  are  keys  to  successful  management  of 
these  environments,  the  Capacity  Management  Function  defined  in  this  document  provides  a 
structured  framework  and  standard  process  that  will  enable  effective  capacity  management  of  all 
DOD  DII/IS  configurations. 
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Use  of  this  framework  and  the  processes  modeled,  will  ensure  that  consistent  methods  for  Capacity 
Management  are  used  across  the  DoD.  These  methods  will  also  produce  credible,  comparable,  and 
reliable  performance  measurements  and  data,  and  install  common  edacity  planning  and  modeling 
activities  in  all  organizational  elements  of  the  DoD  for  all  PC-to-mainffame  (end-to-end) 
configurations. 

PC-to-Mainframe  Concent 

In  the  case  of  the  Ct^acity  Management  Function,  the  PC-to-mainffame  (end-to-end)  concept  is 
intended  to  describe  all  systems  and  components  of  the  Defense  Information  Infrastructure  (DU).  The 
"PC”  part  of  this  concept  includes  client/workstations,  local  area  networks  (LANs),  wide-area 
networks  (WANs),  communications  systems,  network  backbones,  their  protocols,  etc,  which  connea 
to  the  "MAINFRAME"  end  of  this  concept  through  network  interfaces,  front-end  processors,  etc., 
that  are  used  to  access  mainfirame/host  computers.  A  conceptual  diagram  of  a  PC-to-Mainframe 
environment  follows: 


Figure  2-1.  PC-to-Mainframe  Conceptual  Model. 
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PC-to-Mainframe  Measurement  Capabilities 


The  Workshop  Team  has  documented  the  need  for  PC-to-Mainframe  measurement  ct^abilities  (see 
Improvement  Opportunity  #12.  Measure  PC-to-Mainframe  Response-Times  for  all  DII/IS 
Components).  This  is  needed  if  we  are  to  manage  our  DII/IS  configurations  better,  and  gain  the 
ability  to  detect  variances  in  response-times  in  a  timely  manner. 

The  following  discussion  portrays  how  PC-to-Mainframe  measurements  might  occur  in  DII/IS 
configurations.  Since  our  h^erogeneous  environment  (vendor-specific  hardware,  software,  protocols, 
etc.)  does  not  permit  performance  measurements  between  con^nents  of  such  configurations,  nor  can 
we  always  extract  similar  measurements  from  devices  that  will  present  comparable  data,  it  ^>pears 
that  PC-to-Mainframe  response-time  measurement  capabilities  will  take  some  time  to  become 
available. 

In  the  interim,  we  believe  that  the  alternative  described  herein  will  provide  'indicators"  of  internal  and 
external  device  propagation  delays  which  can  be  viewed  in  a  "peer-to-peer  response-time"  scenario. 
Thus,  the  "internal"  (vendor  supplied)  data  transfer  rates  for  a  specific  device  can  be  stated  as  one 
element  of  the  total  PC-to-Mainframe  response-time  scenario.  The  "external"  transmission  speed  of 
the  communications  path  between  any  one  device  can  be  stated  as  another  element  of  this  same 
response-time  scenario. 

When  we  view  the  entire  combination  of  devices  in  any  specific  configuration,  and  the 
foregoing  time  considerations  to  each  device  in  the  configuration,  we  can  add  them  up  and  get  a  pretty 
good  idea  of  what  PC-to-Mainframe  response-time  should  be  for  that  configuration.  This,  however, 
will  only  give  us  theoretical  indicators  (not  actual)  of  response-time. 

The  next  step  would  be  to  test  these  measures  by  executing  a  PC-to-Mainffame  response-time 
measurement  during  peak  workload  hours  for  this  same  configuration.  An  illustration  of  this 
measurement  process  is  shown  in  Figure  2-2,  Peer-to-Peer  Propagation  Delay  Response-Time 
Measurement. 

In  the  first  column  of  Figure  2-2,  a  sample  PC-to-Mainframe  configuration  is  presented  that 
illustrates  all  of  the  major  components  (devices),  and  the  communication  paths  between  them,  for  a 
typical  configuration  (the  Application  Database  is  shown  last  because  you  must  go  through  the 
Mainframe  to  get  to  the  data). 

The  second  column  represents  the  minimum  ("internal”)  component/device  measurement  (i.e.,  data 
transfer  rate)  as  well  as,  the  minimum  ("external")  conununications  path  transmission  speed. 

The  third  column  is  a  similar  representation  of  component  and  communications  measurement,  but 
these  are  maximum  values  that  would  be  collected  from  real-time  tests  of  the  same  configuration. 

The  iterations  (.xxx)  shown  in  Figure  2-2  across  from  each  component,  represent  time  values  of 
propagation  delays  for  each  component.  The  down  arrow  (i)  represents  ^e  communication  path 
between  the  components,  and  has  similar  time  values  entered  for  time  intervals  computed  for  (1)  types 
of  media,  (2)  communication  path  lengths,  and  (3)  transmission  speeds.  Thus,  we  have  a  "picture"  of 
an  estimated  minimum  and  maximum  expectation  range  for  propagation  delays.  The  "total" 
value  shown  at  the  bottom  of  Figure  2-2,  shows  the  collective  representation  for  (one-way)  PC-to- 
Mainffame  response-time  in  this  configuration  example. 
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Typical  Configuration 
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(Note:  i  =  communication  path  between  components.) 


Figure  2-2.  Peer-to-Peer  Propagation  Delay  Response-Time  Measurements 


If  we  accept  this  illustration  as  being  a  valid  concept  for  estimating  minimum  and  maximum 
propagation  delays,  we  can  use  it  as  a  basis  for  monitoring  response-time  problems  as  experienced  by 
a  user  (at  the  PC  end). 

In  addition,  we  can  also  use  th’s  scenario  during  preparation  of  Service  Level  Agreements,  as  an 
indication  of  what  users  can  expea  in  terms  of  response-times.  This  scenario  may  not  be  ai^licable 
to  all  DU  environments  or  configurations,  but  it  is  a  beginning  toward  resolving  a  very  con^lex 
problem  in  measuring  PC-to-Mainframe  response-time. 
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Capacity  Management  Function  -  Management  Model 


The  diagram  shown  in  Figure  2-3  presents  a  conceptual  view  of  how  the  flow  of  management 
information  might  oco'r  to  be  collected,  reviewed,  or  presented  from  the  C3I  level,  through  the 
Capacity  Management  Function,  and  other  levels  of  management.  The  concept  for  managing  policy 
and  issues  for  the  areas  illustrated,  as  they  relate  to  the  Capacity  Management  Function,  is  a  follows; 

•  "DASD  (IM)  Policy  Level  -  CSI"  -  In  this  scenario,  develops  policy  for: 

•  Capacity  Management  Function,  DII  Architecture,  Configuration  Control  Board  (CCB), 
Open  Systems  Interconnection  (OSI)  requirements.  Cost  Evaluation/Monitoring/ Accounting, 
etc. 

•  "Primary  Functions  Defined"  -  All  of  these  Model 

Activities  apply  equally  to  mainframe,  network,  and  communications  systems. 

•  "Primary  Categories"  -  These  are  logical  separations  of  functional  areas  that  were  used  in  the 
CM  Function  models.  However,  they  may  be  logical  organizational  structures  too,  especially 
in  terms  of  managing  the  DII/IS.  They  are  examples  of  the  categories  of  mainframe,  network, 
and  communication  systems  that  make  up  the  DII/IS,  to  which  the  "Primary  Functions"  are 
applied. 

•  "Management  Issues  &  Reporting"  -  These  are  examples  of  management  oversight  areas  and 
issues  that  would  be  considered  and  managed  by  DISA/DISO.  Reports  to  this  level  would 
come  from  the  Megacenters,  as  well  as,  other  network,  communication,  and  base-level 
structures. 

•  "Policy  Review/Re<<lirection  -  C3I"  -  This  area  represents  executive-level  reporting  at  the  end 
of  the  management  cycle,  and  suggests  a  feedback  loop  occurs  between  DISA  and  C3I  for 
policy  review. 
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DOD  IS  CAPACITY  MANAGEMENT  FUNCTION 
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Figure  2-3.  Capacity  Management  Function  -  Management  Model 


Propect  Objectives 


The  objectives  of  this  project  were  to  define  a  CM  Function  to  promote  standard  cost  efficient  and 
effective  performance  management  and  capacity  planning  of  Information  Systems  (including 
Communications  and  Networks),  and  aid  in  ensuring  that  Information  Systems  resources  are  available 
to  deliver  capacity  and  performance  levels  in  a  timely  manner  at  acceptable  levels  of  satisfaction  to  the 
user  community.  It  is  ^so  necessary  that  this  function  enable  capacity  managers  to  meet  user  Service 
Level  Objectives  (defined  in  Service  Level  Agreements)  by  recognizing  and  forecasting  systems 
resource,  utilization,  workload,  performance,  and  capacity  requirements;  acquiring  resources  in  a 
timely  and  cost-effective  manner;  and  providing  standard  reporting  information  to  upper  management 
in  a  consistent  manner. 

This  project  was  conducted  in  concert  with  the  Defense  Information  Services  Organization  (DISO), 
along  with  participation  from  other  DoD  Services  and  Agencies.  All  DoD  Services  and  Agencies 
were  invited  to  participate  in  the  workshop  series.  The  results  of  this  project  are  viewed  as  an 
effective  way  to  document  the  TO-BE  (future)  capacity  management  processes  that  are  necessary  to 
design  a  DoD-wide  CM  Function,  and  to  provide  efi^ective  management  of  this  function  across  the 
DoD. 

In  summary,  the  achievement  of  these  project  objectives  provides  an  understanding  of  common 
process  requirements  and  permits  streamlining  of  processing  actions.  It  also  fosters  identification  and 
measurement  of  efficiencies,  conservation  of  resources,  empowerment  of  quality  efforts,  and  promotes 
responsive  and  effective  support  functions.  Integration  of  the  results  of  this  project,  with  other 
DISA/JIEO/CIM  and  DISA/DISO  ongoing  initiatives  (that  further  develop  the  CM  Function),  will 
result  in  a  comprehensive  and  inter-related  set  of  processes  that,  when  structured  as  DoD-wide  C3I 
policy,  will  ensure  that  Information  Systems  across  the  DoD  can  be  planned  and  managed  by  the  best 
practices  and  cost-efficient  methods  available. 

DoD/DASD  (IM)  Mission  Statement 

The  Department  of  Defense  has,  through  DMRD  918,  promulgated  the  reduction  of  costs,  and 
establishment  of  Megacenters,  for  Information  Systems  processing  environments  across  the  DoD. 

This  move  toward  PC-to-Mainfianic  (end-to-end)  cost-reduction  for  Information  Systems,  and 
emphasis  on  focused  consolidation  and  management  for  these  systems,  will  require  additions  to  current 
policy  and  planning  as  this  new  environment  is  developed. 

The  DASD  (IM)  has  responsibility  for  policy  development  and  management  of  DoD-wide  Information 
Systems  and.  therefore,  established  the  need  for  an  improved  CM  Function  that  could  be  applied  to  all 
elements  of  the  DII.  The  results  of  this  workshop  will  provide  C3I  with  the  foundation  (along  with 
other  related  and  on-going  C3I  initiatives)  for  development  of  policy  and  management  guidance  for 
implementing  the  CM  Function  across  the  DoD. 
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Issues  Affecting  CM  Policy  Implementation 


As  a  result  of  the  modeling  effort  to  develop  the  Capacity  Management  Function,  the  Workshop  Team 
discovered  a  number  of  issues  that  must  be  address^  if  a  Capacity  Management  (CM)  policy  is  to  be 
successfully  implemented  throughout  the  DoD.  The  following  issues  are  discussed  further  in  Section 
S  Recommendations.  Parenthetical  numbers  provide  cross-references  to  each  improvement 
opportunity  as  they  relate  to  these  issues. 

1 .  Roles  and  Responsibilities 

This  workshop  established  a  need  for  a  Configuration  Control  Board  (CCB)  and  a  Ci^iacity 
Management  (CM)  "Steering  Group"  for  the  purposes  of  managing  and  controlling  performance  and 
planning  activities  of  Defense  Information  Infiastructure  (DU)  Information  Systems  (IS) 
configurations.  (See  discussion  in  Section  5  Recommendations:  Improvement  Of^rtunities  #1,  5,  6, 
10).  It  is  recommended  that  the  CCB  issue  policy  for  controlUng  and  ejecting  changes  to  the  DII 
Information  Systems  (IS)  configurations,  at  all  levels.  The  Steering  Group  should  be  responsible  for 
guiding  a  central  policy,  and  providing  direction  of  DU/IS  Operations  and  CM  Functions  that  afiect  all 
DU  configurations. 

A  probable  scenario  describing  how  levels  of  management  for  the  CM  Function,  and  subsequent 
activities  might  occur  is  as  follows.  Current  planning  indicates  that  C3I  (DASD/IM)  will  prepare 
overall  policy  guidance  for  implementation  of  this  CM  Function  by  all  DoD  elements.  C3I  would  also 
promulgate  in^>lementation  of  the  CCB.  As  a  manager  of  all  DU/IS,  DISA  would  have 
responsibilities  for  mandating  implementation  and  execution  of  the  CM  Function  policy  across  all 
afiected  areas  of  DoD,  and  for  providing  guidance  for  the  interface  of  the  CCB  and  the  CM  Steering 
Group  with  organizational  elements  across  the  DoD. 

This,  in  turn,  would  require  DISO  to  implement  a  CM  Program  (which  is  already  underway)  for  all 
DU/IS  Megacenter  configurations,  as  well  as,  establishing  a  CM  Steering  Group.  Under  this 
scenario,  DISO  would  have  the  lead  for  all  Megacenter  CM  Function  activities,  establishing  standards 
of  management  and  operations,  defining  reporting  requirements  etc.  At  C3I  direction,  DISA  would  be 
responsible  for  coordinating  CM  Functions,  etc.,  with  Services  and  Agencies  that  would  occur  at 
base-level  or  in  other  organizational  structures,  and  promote  standards  for  CM  execution. 

2.  Standards 

A  key  element  to  effective  implementation  of  CM  poUcy  will  be  the  promulgation  of  standards  for  use 
among  all  DU  Information  Systems  and  components.  This  includes  standard  practices  for  managing 
CM  Functions,  providing  standard  software  measurement  tools,  ensuring  interoperability  in  design, 
ensuring  standard  data  collection  practices,  providing  standard  modeling  capabilities,  and  producing 
standard  reports. 

The  activities  defined  in  the  models  in  this  document  enable  the  development  and  use  of  standards  for 
performing  CM  across  all  elements  of  the  DU.  The  comprehensive  and  "generic"  approach  taken  in 
building  these  models  was  designed  to  promote  standard  use  for  computer,  communications,  or 
networking  environments.  However,  standards  must  also  be  developed  to  ensure  (^abilities  of 
performance  measurement  across  system  platforms  and  configurations. 
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3.  Reporting 

A  significant  aspect  of  managing  a  CM  Function  is  obtaining  information  on  subjects  such  as; 
performance  measurements,  achievement  of  service  objectives,  capacity  availability  and  usage, 
resource  utilization,  cost-performance  analyses,  workload  statistics,  on-line/network  traffic  loads, 
communications  performance  trends,  file  server  performance,  etc.  All  of  these  reports,  and  more  (See 
Capacity  Management  Reporting  Requirements,  Table  4-5)  must  be  provided  to  various  levels  of 
management  on  a  periodic  basis.  These  reports  will  provide  information  that  is  needed  to  evaluate 
performance  and  capacity  of  DII/IS  components,  as  well  as,  monitor  activities  associated  with 
performance  in  meeting  user  service-level  objectives. 

To  ensure  their  credibility,  and  utility  in  comparing  reported  information  (e.g.,  between  Megacenters, 
configurations,  etc.)  all  reports  must  have  standard  origins  at  each  reporting  "center",  and  must  also 
be  drawn  from  the  same  base  of  information.  This  CM  Function  model  provides  for  this  process. 

4.  Cost  Accounting 

It  is  necessary  to  enable  the  CM  Function  to  determine  certain  costs  associated  with  its  activities. 

This  can  be  achieved  through  a  Fee-for-Service  or  cost-recovery  (e.g..  Chargeback)  system.  Through 
such  a  system,  we  can  view  some  aspects  of  the  CM  Function  as  "an  application",  and  measure  the 
amount  of  capacity  being  used,  as  well  as.  attribute  the  unit  cost  of  this  usage  in  terms  of  dollars. 

This  will  help  to  understand  costs  for  most  activities  of  the  CM  Function,  justify  higher  levels  of 
capacity  requirements,  and  predia  the  cost  of  achieving  user  performance  objectives. 

A  benefit  of  cost  accounting  that  is  of  added  value  to  CM,  is  the  ability  for  the  CM  Function  to 
integrate  cost  information  into  models  associated  with  performance,  feasibility  studies,  configurations, 
etc.  Thus,  the  "cost  of  doing  business,"  and  cost-effectiveness  of  related  performance  services  (e.g., 
response-time  improvements,  improved  failure  ratios  MTBF,  reduction  of  networking  and 
communications  overhead)  can  be  accurately  described. 

5.  Organizational  Structures 

To  facilitate  implementation  of  a  CM  policy,  it  is  necessary  to  ensure  that  an  adequate  organizational 
structure  is  defined  that  will  foster  effective  implementation  of  the  CM  Function  at  the  program 
execution  level.  Further,  because  Capacity  Management  is  a  full-time  activity,  it  should  occupy  a 
prominent  position  in  the  organizational  hierarchy,  along  with  other  organizational  elements  (e.g.,  the 
applications  division,  software  division,  etc.). 

Placing  the  CM  Function  in  an  organizational  structure  equal  to  other  organizational  elements  (e.g., 
applications,  operations,  etc.),  will  permit  CM  management  to  take  a  pro-active  and  equal  role  in 
decision  making  regarding:  tasking,  system  performance,  capacity  planning,  funding,  staffing,  and 
other  issues.  Further,  being  on  an  appropriate  level  of  management  will  ensure  that  CM  managers 
have  direct  access  to  appropriate  Megacenter,  IPC,  etc.,  management  levels.  This  will  also  aid  in 
ensuring  that  the  CM  Function  has  an  integral  role  in  the  life-cycle  system  design  and  implementation 
process. 

6.  Centralized  Management  Control  and  Distributed  Execution 

This  is  a  concept  of  management  that,  if  used  for  the  CM  Function,  would  permit  all  DII/IS 
environments  (e.g.,  CDAs,  Megacenters,  IPCs,  base-level  installations,  large  networked 
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environments,  etc.),  to  provide  local  support  to  their  user  communities  for  system  performance, 
appUcation  development,  and  system  design  efforts,  etc.,  while  providing  a  central  higher-level 
management  of  all  DoD  Capacity  Management  activities.  This  concept  would  also  foster  management 
control  (oversight)  for  establishing  performance  objectives,  standards,  reporting,  and  other 
requirements  common  to  all  DoD  organizations,  while  giving  "local”  sites  (e.g..  Megacenters,  IPCs, 
base-level  installations,  etc.)  the  latitude  to  ensure  effective  execution  of  the  CM  Function. 

Thus,  the  day-to-day  activities  of  CM  would  occur  at  a  level  where  close  working  relationships  and 
performance  monitoring  are  needed,  yet  ensure  that  upper  management  could  establish  standards  and 
level  of  oversight  required.  However,  in  the  short-term  (1-2  years)  this  distributed  execution  concept 
might  need  revision  to  accommodate  a  future  "lights  out"  or  remote  Capacity  Management  operations 
concept,  when  centralized  execution  might  be  more  ^ropriate. 

7.  Implementation  Support 

Effective  implementation  of  C3I  policy  for  this  Capacity  Management  Function  will  require  the 
concurrence  and  support  of  top  management  at  all  DoD  Services  and  Agencies,  C3I,  DISA,  DISN, 
and  DISO.  Further,  if  the  implementation  of  C3I  policy  for  this  CM  Function  is  to  be  effective,  a 
management  plan  must  be  developed  to  foster  incorporation  and  establishment  of  all  aspects  of  this 
CM  Function  at  DOD  organizations.  A  central  liaison  for  all  Services  and  Agencies  would  help 
understanding  and  implementation  of  the  CM  Function. 

8.  Baseline  DII/IS  Models 

A  significant  element  of  this  CM  Function  is  the  requirement  for  constructing  Capacity  Management 
models  of  hardware  and  software  components,  as  well  as,  computer  systems,  communications,  and 
network  components.  Often,  documentation  in  these  areas  is  incomplete  and  there  are  no  "baseline" 
models  available  that  can  be  used  for  documentation,  illustration,  performance  prediction,  "what  ir 
scenarios,  workload  characterization,  cost-performance  ratio  analysis,  etc. 

This  report  presents  a  baseline  modeling  approach  for  Capacity  Management  that  is  prescribed  for  use 
in  all  DII/IS.  Use  of  this  approach  will  (1)  promote  consistency  in  modeling,  (2)  ensure  that  models 
are  available  for  upgrading  systems  and  other  uses,  (3)  permit  interoperable  information  exchange 
between  various  system  configurations,  and  produce  standard  reporting  results. 

These  Capacity  Management  (CM)  models  will,  generally,  be  mathematical  representations  of  DII/IS 
configurations.  They  will  be  used  to  measure  queuing  statistics,  predict  systems  performance, 
simulate  workloads,  benchmark  vendor/system  charaaeristics,  etc.  Not  all  models  used  or  created  in 
the  CM  Function  will  originate  there.  The  CM  Function  will  also  require  the  use  of  models  produced 
by  the  Configuration  Management  staff.  These  models  will  be  used  to  evaluate  DII/IS  component 
configuration  changes,  response-times,  verify  the  effect  of  upgrades,  etc. 

9.  Life-cycle  Design  and  Development 

In  mainffame/host,  network,  and  communications  environments,  user  computing  requirements  are  at 
the  beginning  of  the  life-cycle  design.  Whether  these  activities  are  performed  at  a  (TDA,  DISN, 
Megacenter,  or  base-level  military  installation,  perfonnance  and  capacity  are  always  major  issues  to 
be  resolved.  Because  the  very  nature  of  design  indicates  performance  requirements  must  be  met,  it  is 
essential  that  the  CM  Function  become  a  part  of  the  application  or  system  development  life-cycle 
process,  from  the  beginning  to  implementation.  The  CM  Function's  role  in  life-cyle  processes  would 


2-12 


include:  monitoring  test  scenarios,  evaluating  the  performance  feasibility  of  an  application  or  DU/IS 
component  or  system  design,  and  providing  reconunendations/feedback  (e.g.,  feasibility  of  meeting 
performance  objectives,  etc.)  to  the  development  community. 

An  illustration  of  a  typical  life-cycle  process  in  which  Capacity  Management  would  play  a  role,  is 
presented  in  Figure  2-4  Typical  Life  Cycle  Design  and  Development  Process  on  pages  2-14  to  2-15. 
This  figure  displays  areas  of  performance  measurement  or  performance  modeling  that  are  required 
during  the  design  and  development  required  during  the  design  and  development  {biases  in  satisfying 
user  service  objectives. 

10.  Staffing  Requirements 

The  Capacity  Management  Function  normally  requires  a  variety  of  management  and 
professional/technical  skills,  experience,  and  knowledge.  Implementing  the  TO-BE  Capacity 
Management  Function  (e.g.,  performance  measurement,  capacity  planning,  configuration  modeling, 
etc.)  for  DII  Information  Systems  (including  networks  and  communication  systems)  will  require 
expertise  in  these  and  other  CM  Functional  areas  (e.g.,  LANAVAN  performance,  optical  fiber  FDDI, 
etc.) 

Some  areas  (e.g.,  local  area  networks)  may  not  have  adequate  tools  or  measurement  capabilities  to 
collect  required  reporting  data.  However,  adequate  staffing  levels  and  skill  sets  must  be  provided  to 
ensure  that  day-to-day  performance  management,  data  collection  and  analysis,  and  planning  for  any 
DII  configuration  is  successful. 

(Note:  DISA/JIEO/CIM/XI  currently  has  an  on-going  project  to  examine,  customize,  and  prepare 
skill  sets,  etc.,  that  will  be  needed  to  perform  the  Capacity  Management  Function.) 

11.  Training 

A  number  of  the  CM  functional  activities  described  in  this  report  will  be  new  to  some  IPCs  and 
Megacenters.  Many  of  these  CM  activities  are  not  performed  in  many  centers;  especially  in 
communication  or  networking  environments.  Therefore,  it  will  be  necessary  to  develop  training 
programs  to  provide  for  the  various  skills  and  skill-levels  needed  for  effective  execution  and 
management  of  these  CM  functional  areas.  A  policy  that  establishes  training  "requirements”  in  terms 
of  skill  levels  to  be  maintained,  is  needed  to  ensure  that  each  site  performing  the  CM  Function  has 
adequate  numbers  of  trained  personnel  to  take  care  of  day-to-day  technical  processes  such  as 
performance  monitoring,  as  well  as,  capacity  planning  and  modeling  activities. 

12.  Improvement  Opportunities 

A  number  of  the  improvement  opportunities  listed  in  this  report  (See  Section  S  Recommendations)  are 
integral  parts  of  the  TO-BE  model  for  this  CM  Function.  Many  of  these  improvement  opportunities 
have  been  incorporated  into  the  models  as  they  were  built.  It  is  recommend^  that  all  of  the 
improvement  opportunities  be  implemented  since  they  provide,  in  most  cases,  a  direct  impaa  on  the 
effective  implementation  of  C3I  policy  for  the  CM  Function. 
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Figure  2-4 

Typical  Life-Cycle  Design  and  Development  Process 
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Figure  2-4 

Typical  Life-Cycle  Design  and  Development  Process  (Continued) 
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Discussion  and  Recommended  Guidelines  for  CM  Policy 


The  workshop  team  recognizes  that  implementation  of  this  Capacity  Management  (CM)  Function 
across  the  entire  Department  of  Defense  (DoD)  will  require  understanding,  cooperation,  and  planning 
by  all  DoD  Services  and  Agencies.  For  this  implementation  to  be  successful,  a  comprehensive  and 
DoD-wide  application  of  these  CM  functional  activities  must  occur. 

This  will  require  executive-level  management  commitment  and  support  by  each  DoD  Service  and 
Agency.  Participation  of  senior  management  includes  providing  the  authority  for  implementing  and 
executing  the  CM  Function,  as  well  as,  establishing  overall  objectives  and  standards,  defining 
reporting  requirements,  and  ensuring  all  the  elements  needed  for  a  quality  CM  Function  are  in  place. 
These  elements  include,  funding,  procurement  vehicles,  adequate  staffing  levels  and  skills,  backup 
disaster  recovery  capability,  cost-recovery  process^  (e.g.,  "chargeback"),  etc.  Further,  senior 
management  must  ensure  that  this  CM  Function  is  incorporated  into  all  DII/IS  performance,  planning, 
and  life-cycle  activities  for  mainframes,  networks,  and  communication  systems. 

Since  there  are  many  capacity  management  (or  other  named  "performance")  programs  in  place  for 
Information  Systems  throughout  the  DoD,  C3I  policy  should  promulgate  this  CM  Function  as  the 
target-objective  program  to  be  implemented  by  all  Services  and  Agencies,  over  a  specific  period  of 
time. 

This  CM  Function  is  designed  to  promote  standard  CM  practices  and  reporting  for  all  levels  of 
management.  Although  the  "mainframe"  area  of  the  DII  has  used  capacity  management  processes  for 
a  longer  period  of  time,  standard  performance  measurement  data  are  available  for  most  (if  not  all) 
computers,  networks,  and  communication  systems.  (However,  the  lack  of  interoperability  of  many 
network  protocols  is  still  a  problem,  and  comparability  of  report  content  is  often  not  possible.) 

Overall  C3I  policy  must  encourage,  support,  and  require  that  common  standards  and  measurement 
capabilities  for  performance  measurements,  ci4)acity  planning,  performance  prediction  (e.g.,  for 
workloads,  system  operations,  networked  user  configurations)  etc.,  are  identified  and  used  for  all 
DII/IS  configurations. 

It  is  through  these  standard  CM  practices  that  planning  for  current  and  future  DII/IS  requirements  can 
be  documented,  and  addressed  from  comparable  sources,  that  will  illustrate  (through  various  levels  of 
detail)  what  the  "big  picture"  looks  like. 

Thus,  standard  reporting  prncUces  will  enable  senior  management  to  make  knowledgeable  decisions 
affecting  changes  to  operational  systems,  procurement  of  new  systems,  development  of  funding 
requirements,  preparation  of  justifications  for  enhancements,  merger  of  systems,  etc. 

(Note:  These  recommended  guidelines  are  supported  throughout  the  narrative  text  in  Section  2  of  this 
report,  and  the  recommendations  in  Section  S  [Improvement  Opportunities].) 
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Next  Steps  Toward  Implementation 


The  results  of  this  workshop  will  provide  C3I  with  the  foundation,  along  with  other  related  and  on¬ 
going  C3I  initiatives,  to  develop  policy  and  management  guidance  for  implementing  the  CM  Function 
across  the  DoD. 

Next  steps  include  delivery  and  briefing  of  the  workshop  results  to  DISA  and  the  Deputy  Assistant 
Secretary  of  Defense  for  Information  Management  (DASDAM)  C31,  (who  sponsored  this  project),  and 
to  Defense  Information  Services  Organization  (DISO).  DISO  has  been  a  full  time  participant  in  the 
development  of  this  Capacity  Management  Function  and  is  preparing  to  use  results  of  this  workshop  in 
their  implementation  planning  for  edacity  Management  in  the  new  Megacenter  environment. 

Upon  completion  of  this  workshop  effort,  DISA/JIEO/CIM  (Joint  Interoperability  &  Engineering 
Organization/Center  for  Information  Management)  will  assist  both  DASD/IM  C3I,  and  DISO,  in  their 
efforts  to  implement  this  CM  Function  across  the  DoD.  Additional  DISA  efi^orts  may  include  (at  C3I 
direction)  assisting  all  DoD  Services  and  Agencies  in  understanding  and  implementing  this  Capacity 
Management  Function. 
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Workshop  Mission 


The  mission  of  this  Capacity  Management  workshop  is  to  define  and  prepare  a  TO-BE  (future)  DU 
model  of  activities  and  data  for  ;  CM  Function,  and  to  develop  comprehensive  templates  that  can  be 
used  DoD-wide  across  all  Information  Systems  (IS)  and  networked  components.  This  workshop  is 
intended  to  provide  integrated  models  that  can  be  used  DU-wide,  and  that  DASD  (IM)  can  use  as  a 
basis  for  developing  CM  policy  and  guidance. 

Workshop  Objectives 

The  objectives  of  the  workshop  were  to: 

(1)  Identify,  document,  and  model  all  primary  DoD  Capacity  Management  practices  and  Activities 
including: 

•  Identify  Requirements  Support  Activities 

•  Elements  of  Capacity  Management 

•  Capacity  Planning  Practices 

•  Performance  Measurement  and  Monitoring  Processes 

•  CDA  System  Development  Processes 

•  CM  Project  Management  Activities 

•  Baseline  Capacity  Management  Modeling  Processes 

(2)  Transform  the  baseline  AS-IS  model  into  a  TO-BE  model,  eliminating  non-value  added 
processes  and  providing  the  additional  functionality  to  meet  future  DoD  DII/IS  requirements, 
while  adhering  to  "best  business  practices". 

(3)  Focus  on  defining  a  Dll-wide  activity  model,  and  discovering  improved  CM  functional 
processes  for  Megacenter /Mainframe  and  Communications  Network  environments.. 

(4)  Produce  a  foundation  model  to  provide  input  to  C3I  policy,  and  the  design  of  a  strategic  CM 
plan  to  aid  implementation  at  the  operational  level  (e.g.  DISO,  DISN  base-level  military 
installations,  CDAs,  Network  and  Communications  Centers,  etc.) 

Workshop  Scope 

The  scope  of  this  workshop  is  to  define  the  TO-BE  process  and  data  models  for  the  DoD  Information 
Systems  Capacity  Management  Functional  Activity.  This  scope  covers  the  PC-to-Mainframe  (end-to- 
end)  environment  of  the  Defense  Information  Infrastructure  (DII),  including  Megacenters/Mainftames, 
CDAs,  Networks,  DISN,  and  Client/Server  and  distributed  architectures  to  which  the  CM  Function 
will  eventually  be  applied  to  foster  end-to-end  Capacity  Management  capabilities. 
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Table  2*1.  Workshop  Schedule  (Continued) 
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The  participants  who  provided  the  energy  and  talent  to  accomplish  this  workshop  are  listed  below. 
The  Core  Team  members  shown  are  experts  in  the  field  of  Capacity  Management,  provided  the 
fundamental  model  design,  and  produced  the  content  of  this  report.  The  Subject  Matter  Experts 
(SMEs)  were  brought  in  at  various  times  to  provide  specific  knowledge  to  the  model  development 
process. 


NAME 

AFFILIATION 

ROLE 

PHONE  NUMBER 

Tom  Adkins 

NCTC 

Core  Team  Member 

(202)  282-0784 

Cliarles  Archer,  Sr. 

DISA/JffiO/CIM/XII 

Core  Team  Member 

(703)  285-5323 

Dean  Eads 

DISO-UFCSH 

Core  Team  Member 

(513)  257-7751 

James  Haskins 

DLA  (DSAC) 

Core  Team  Member 

(614)  692-9432 

Lawrence  Lewandowski 

DISO-UMILTP 

Core  Team  Member 

(216)  522-5935 

Richard  Robinson 

DISA-UNRRB 

Core  Team  Member 

(614)  692-9965 

John  Bayley 

USAISSC 

Subjea  Matter 

Expert 

(703)  806-3583 

Lindsay  Carpen 

DISA/CFE  (TEGBN) 

Subject  Matter 

Expert 

(703)  487-3332 

Mary  Eskridge 

DLA  (DSAC) 

Subject  Matter 

Expert 

(614)  692-9430 

Hal  Folts 

DISA/CFE 

Subject  Matter 

Expert 

(703)487-3121 

James  Howard 

DISA/CFE 

Subject  Matter 

Expert 

(703)  487-3106 

Steve  Hughes 

DLA/DSAC-RMB 

Subject  Matter 

Expert 

(614)  692-8266 

James  Kilgore 

DISA/CIM 

Subject  Matter 

Expert 

(703)  285-5323 

Eric  Meister 

DISA/DISO 

Subject  Matter 

Expert 

(703)  285-5185 

Lou  Morgan 

DISA/DISPO 

Subjea  Matter 

Expert 

(703)  285-5045 

Ron  Torezan 

DASD  P&R  (TTR) 

C3I 

Subjea  Matter 

Expert 

(703)  614-1996 

Table  2-2.  Workshop  Team. 
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The  Review  Team  was  a  group  of  senior  OSD  and  DISA  managers  who  participated  in  a  weekly 
workshop  review  process  which  was  designed  to  provide  feedback  to  the  core  team,  and  support 
production  of  a  quality  workshop  product. 


NAME 

AFFILIATION 

ROLE 

PHONE  NUMBER 

Bill  Beyer 

DASD  P«feR  (ITR) 

C3I 

Review  Team 

Member 

(703)  614-1953 

John  Hunter 

DISO-UAT 

Review  Team 

Member 

(703)  285-5195 

Mark  Scher 

DISA/JIEO/CIM/XI 

Review  Team 

Member 

(703)  285-5323 

Jack  Williams,  Jr. 

DISO  DCSOPS 

Review  Team 

Member 

(301)  878-5595 

Warren  Woolsey 

DISA/CFE  (TEGBN) 

Review  Team 

Member 

(703)  487-3332 

Table  2-3.  Review  Team. 


NAME 

AFFILIATION 

ROLE 

PHONE  NUMBER 

Steven  Stark 

D.  Appleton 

Company,  Inc. 

Facilitator 

(703)  812-8666 

Catherine  Wood 

D.  Appleton 

Company,  Inc. 

Assistant  Facilitator 

(703)  812-8666 

Stacey  Kenton 

D.  Appleton 

Company,  Inc. 

Technical  Analyst 

(703)  812-8666 

Table  2-4.  Facilitation  Team. 
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!ore  Team  Member  Profiles 


NAME  PROHLE 


Tom  Adkins 

Naval  Computer  and  Telecommunicabons  Command. 

Head  of  DPI  Operations  for  nine  regional  computer 
centers.  Responsibihties  include:  Performance 

Management,  Systems  Software,  and  Capital  Purchase 
Programs. 

Charles  Archer,  Sr. 

Projea  Manager  for  CM  in  the  Defense  Information 
Systems  Agency,  Joint  Interoperabihty  &  Engineering 
Organization,  Center  for  Information  Management 
(DISA/JIEO/CIMyXII).  Project  Manager  and  Action 
Officer  for  the  DoD  Information  Systems  Capacity 
Management  Funcbon  for  C3I. 

Dean  Eads 

Serves  as  lead  of  the  Capacity  and  Performance 
Management  (CPM)  function  in  the  Defense  Information 
Services  Organization  -  Air  Force  Information  Service 
Center  (DISO  -  AITSC),  Systems  Engineering  Office, 
Hardware  Management  Division.  Responsible  for 
conducting  the  DISO  -  AFISC  Capacity  and  Performance 
Management  Program. 

James  Haskins 

Serves  as  the  Chief,  CM  Division  in  the  DLA  Systems 
Automation  Center.  Responsible  for  conducting  the 

DLA  CM  Program. 

Lawrence  Lewandowski 

Defense  Information  Services  Organization  -  Cleveland 
Center  (DISO-CL).  Chief,  Technical  Platforms.  Lead 
Center  for  Technical  Platforms  for  DISO. 

Richard  Robinson 

Serves  as  Chief,  Configuration  Management  Branch  at 
the  DISN  Level  II  Network  Management  Center  in 
Columbus,  OH  (DISA-UNRRB).  Responsible  for 
configuration  management  of  the  DISN  elements 
managed  by  the  center.  Formerly  responsible  for  wide 
area  network  design  and  the  development  of 
telecommunications  connectivity  solutions  for  the 

Defense  Logistics  Agency. 

Table  2-5.  Core  Team  Member  Profiles. 
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Section  3 
Approach 


Corporate  Information  Management  Methodology 

Adherence  to  the  Corporate  Information  Management  (CIM)  methodology  is  an  integral  part  of  the 
strategy  for  DoD  Capacity  Management.  The  focus  of  the  CIM  initiative  is  to  affect  process 
improvement  within  DoD  through  analysis,  simplification,  and  elimination  of  non-value  added 
activities,  and  to  employ  technological  solutions  against  proven  areas  in  support  of  fiinctional  cost 
reductions. 

The  main  focus  of  the  CIM  initiative  is  on  process  improvement  and  the  requirement  to  develop  a 
business  case  before  specifying  policy  and/or  sqjproving  the  development  of  new  information  systems. 
CIM  objectives  include  managing  DoD  system  investments  to  involve  the  migration  and  evolution  of 
assets  already  in  place,  pointing  to  development  of  shared  data  systems  and  software  reuse.  To  meet 
these  objectives,  the  CIM  methodology  requires  the  development  of  a  functionally  oriented  business 
case  that  supports  the  concept  of  continuous  process  modernization  and  improvement  as  the  way  of 
doing  business  within  DoD.  To  achieve  its  objectives  CIM  has  stated  three  principles  that  will  guide 
its  efforts  (as  taken  from  the  CIM  Process  Improvement  Methodology  for  DoD  Functional  Manager's 
guide); 


•  The  customer  (the  functional  proponent  with  business  process  authority  and  performance 
accountability)  defines  systems  requirements,  manages  implementation  and  measures  results. 
The  information  technology  organization  becomes  a  fee-for-service  technology  service. 

•  The  business  process  must  be  simplified  before  it  is  computerized.  Effectiveness  is  gained  and 
cost  is  reduced  by  changing  the  way  people  work. 

•  Fastest  progress,  at  lowest  risk,  is  achieved  by  evolutionary  migration.  Organizations  learn 
best  by  experiencing  frequent  successes. 

The  ftmctional  management  process,  as  promulgated  by  DoD  8020. 1-M,  is  the  key  directive  of  the 
CIM  program,  and  is  the  official  guide  to  achieving  functional  process  improvements.  In  accordance 
with  this  directive,  the  Office  of  the  Secretary  of  Defense  (OSD)  Principle  Staff  Assistants  are 
responsible  for  the  development  of  functional  objectives,  analysis  of  the  processes,  data  and  supporting 
information  systems  needol  to  satisfy  these  objectives,  development  of  any  necessary  process,  data, 
and  systems  changes  to  streamline  operations  and  i^^}rove  cost  effective  performance,  and 
implementation  of  the  process,  data  and  system  changes.  OSD  Principal  Staff  Assistants  designate 
Functional  Activity  Program  Managers  (PMs)  accountable  for  execution  of  the  ftmctional  management 
process.  PMs  develop  ftmctional  architectures  and  strategic  plans,  and  establish  the  process,  data  and 
information  system  baselines  to  support  ftmctional  activities  within  the  ftmctional  area.  PMs  then 
conduct  a  structured,  iterative  process  improvement  program  that  identifies,  analyzes  and  evaluates 
opportunities  to  evolve  operations  toward  the  ftmctional  objectives. 
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Functional  Process  Improvement  Program 


The  Functional  Process  Improvement  program  (FPIP)  was  established  to  implement  the  CIM 
objectives  through  application  of  process  improvement  principles  across  Services  and  Agencies.  It 
encompasses  the  general  concepts  and  steps  associated  with  business  process  improvement  as  well  as 
the  business  case  when  considering  investments.  The  FPEP  entails  a  series  of  steps  aimed  at  identifying 
problem  areas,  formuladng  strategies  for  improvement,  and  assisting  the  change  proponents  in  selling 
the  plan  to  the  key  players  in  the  approval  process.  These  steps  are  typically  undertaken  within  the 
forum  of  a  workshop,  where  functional  experts  embark  on  a  mission  of  information  collection, 
analysis,  discovery,  and  strategy  formulation. 

Specific  methodologies  adopted  and  incorporated  in  FPIP  include  the  use  of  Integrated  Definition 
(IDEF)  modeling  and  Activity  Based  Costing  (ABC)  techniques  for  the  facilitation  of  business  process 
improvement.  IDEF  modeling  techniques  have  been  used  successfully  by  both  the  private  and  public 
sectors  for  several  years.  IDEF  was  created  to  define  advanced  concepts,  techniques  and  procedures 
for  developing  logical  models  to  display  semantic  characteristics  of  a  business  environment.  These 
semantic  models  serve  to  support  business  process  improvement  determination,  management  of  data  as 
a  resource,  integration  of  information  systems,  and  building  of  computer  databases.  ABC  is  a 
disciplined  application  of  cost  factors  to  discrete  activity  work  breakdown  structures  of  a  functional 
area  under  analysis.  The  resulting  cost  structure  serves  to  suppon  analysis  and  determination  of 
improvement  opportunities  for  process  change  and  subsequent  cost  reduction.  Each  decision, 
beginning  with  migration  system  selection  and  continuing  through  iterative  process  improvement  and 
information  system  technical  enhancement,  is  based  upon,  and  documented  through,  preparation  of 
Functional  Economic  Analyses  (FEAs).  Preliminary  FEAs  are  used  by  functional  area  program 
managers  to  evaluate  alternatives  and  select  a  preferred  course  of  action.  Final  FEAs  that  incorporate 
detailed  data  administration  and  information  system  requirements  are  used  to  secure  OSD  Principal 
Staff  Assistant  approval  to  proceed  with  execution. 

Using  these  techniques,  a  formal  process  improvement  methodology  is  followed  when  business 
processes  are  analyzed.  This  methodology  is  used  to  understand  the  current  working  environment  in 
terms  of  its  activities  in  order  to  apply  metrics  for  improvement,  characterize  the  value  or  need  of 
each  activity,  and  rank  activities  for  improvements,  llie  ultimate  goal  is  to  provide  a  foundation  for 
and  facilitate  continuous  process  improvement.  The  key  elements  comprising  the  process  (as  identified 
in  the  CIM  Process  Improvement  Methodology  For  DoD  Functional  Managers  guide)  include; 

•  Building  a  model  and  establishing  cost  and  performance  measures  of  the  baseline  to  be  able  to 
demonstrate  improvements; 

•  Identifying  and  eliminating  non-value  added  activities; 

•  Emphasizing  reuse  of  assets  where  possible; 

•  Automating  only  after  the  underlying  business  process  has  been  cleaned  up;  and 

•  Aligning  goals,  policies  and  procedures  within  the  CIM  Integration  Architecture. 
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CIM  Business  Process  Improvement  Workshops 


CIM  Business  Process  Improvement  Workshops  are  designed  to  provide  DoD  functional  managers 
with  an  understanding  of  the  business  process  improvement  objectives  associated  with  the  CIM 
initiative.  The  workshops  enable  functional  managers  to  identify  current  problems,  establish  business 
activity  costs,  propose  change  alternatives  and  implement  process  improvements  in  their 
organizations.  The  CIM  methodology  employs  established  modeling  techniques,  (e.g.,  IDEFO, 
IDEFIX,  Activity  Based  Analysis,  Activity  Based  Costing  (ABC),  etc),  to  aid  in  the  discovery  of 
process  inefficiencies,  costly  non- value  added  activities  and  poor  business  practices.  For  reference,  a 
guide  to  IDEF  modeling  techniques  is  contained  in  Appendix  A. 

A  typical  sequence  of  workshops  begins  with  a  two  week  Baseline  Workshop  that  identifies  one  or 
more  specific  areas  for  process  improvement.  The  workshop  team  explores  a  wide  range  of  business 
processes  and  assesses  the  quality  of  the  AS-IS  process.  From  this  analysis,  improvement  targets  are 
identified  and  documented  to  become  the  subject  of  follow-on  workshops. 

Capacity  Management  ABA  Process  Improvement  Workshop  Approach 

The  s^roach  used  in  this  workshop  differs  from  traditional  ABC  Foundation  workshops,  due  to  the 
need  to  rapidly  develop  the  TO-BE  activity  and  data  models  for  the  future  CM  Function.  ABC 
foundation  cost  analysis  techniques  were  not  used  in  this  workshop,  although  future  workshops  for 
CM  may  well  involve  detailed  cost  analyses. 
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Section  4 

Activity  and  Data  Models 


Introduction  to  Activity  Models 

The  team  develops  workshop  core  activity  models  from  their  collective  knowledge  about  the  process 
during  facilitated  sessions.  Subject  matter  experts  are  interviewed  on  areas  determined  to  be  outside 
the  team's  colie  ^  ve  expertise.  They  may  also  gain  knowledge  and  insight  into  processes  through 
available  materials  (e.g.,  documents,  forms,  procedures,  and  existing  activity  models,  etc.).  The 
scope,  purpose,  and  viewpoint  are  boundaries  that  help  the  team  determine  what  is  relevant  for 
inclusion  in  the  models.  A  detailed  explanation  of  IDEF  modeling  techniques  is  provided  in  ^)pendix 
A. 

An  activity  model  has  three  components: 

•  Node  Tree  Diagrams 

•  Context  Diagram 

•  Deconqrasition  Diagrams 


Node  Tree  Dia 


Node  tree  diagrams  are  used  to  portray  activities  in  a  hierarchical  format.  Each  activity  is  represented 
by  a  dot.  The  parent  activity  that  entails  the  scope  of  the  activity  model  is  placed  above  its  component 
sub-activities,  with  lines  connecting  the  top  node  to  each  sub-activity  node.  The  sum  of  the  sub¬ 
activities  equal  the  whole  of  a  con:q)lex  activity.  It  is  analogous  to  a  work  breakdown  structure.  The 
component  nodes  may  be  further  decomposed  into  sub-components,  until  a  level  is  reached  that 
adequately  represents  the  required  activity  breakctown.  Ea(^  node  is  labeled  with  the  name  of  the 
activity  or  sub-activity  it  rq)resents,  with  an  additional  identifier  consisting  of  a  letter  followed  by  one 
or  more  numerals.  A  node  tree  diagram  is  often  thought  of  as  a  table  of  contents  for  the  activity 
model.  As  such,  it  depicts  the  breadth  of  the  business  area  being  modeled  and  the  dq)th  of  the 
modeling  effort. 


Perform  Capacity  Management  Node  Tree 

The  node  tree  produced  in  the  DISA  Capacity  Management  ABA  Workshop  on  the  following  page,  is 
developed  to  represent  the  scope  of  the  activities  being  modeled.  The  node  trees  show  the  activities 
and  the  associated  sub-activities.  Each  node  or  dot  on  the  diagrams  represents  a  significant  activity, 
and  each  line  represents  a  decomposition  relationship  between  the  activities.  These  models  are  created 
as  a  decomposition  of  the  AO  Activity  Perform  Capacity  Management. 
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NODE:  TITLE:  VIEWPOINT: 

NODE  TREE  PERFORM  CAPACITY  MANAGEMENT  DII/DASD(IS) 
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Context  Diagram 

The  parent  activity  represented  in  the  context  diagram  is  equivalent  to  the  top  most  activity  node  in  the 
node  tree  diagram.  A  context  diagram  consists  of  a  single  activity  box  and  its  related  inputs,  controls, 
outputs,  and  mechanisms  (ICOMs).  The  context  diagram  establishes  the  scope  of  the  process  being 
moiled.  ICOMs  are  used  to  represent  information  or  materials  used  in  or  produced  by  an  activity, 
and  data  or  objects  involved  in  an  activity.  The  ICOM  names  or  labels  are  nouns  and  noun  phrases. 
An  ICOM  has  four  possible  roles  relative  to  an  activity: 

*  Input.  Information  or  materials  which  are  transformed  or  consumed  in  the  production 
of  the  outputs  of  an  activity.  (Arrow  entering  left  side  of  an  activity  box.) 

•  Control.  Information  or  materials  that  govern,  constrain,  or  trigger  the  operation  of 
an  activity.  It  regulates  the  transformation  of  inputs  to  outputs.  (Arrow  entering  the 
top  of  an  activity  box.) 

*  Output.  Information  or  materials  that  are  produced  by  an  activity  or  results  from  an 
activity.  (Arrow  leaving  the  right  side  of  an  activity  box.) 

•  Mechanism.  People,  machines,  resources  or  existing  systems  that  perform  (enable)  an 
activity,  or  provide  energy  to  an  activity.  (Arrow  entering  the  bottom  of  an  activity 
box.) 

The  scope  for  the  current  modeling  effort  was  initially  identified  and  recommended  by  the  DISA 
Capacity  Management  Baseline  Workshop  completed  2  July  1993.  The  scope  of  that  two-week  effort 
focused  modeling  the  AS-IS  process  of  the  CM  function  for  DoD  Megacenters  and  their  Central 
Design  Activity  (CD A)  Interfaces. 

This  ABA  Workshop  focused  on  modeling  the  TO-BE  processes  of  "Perform  Capacity 
Management"  across  Mainframe,  Megacenters,  Networks  and  Communication  Systems.  The  team 
developed  the  AO  level  for  this  model,  using  the  baseUne  model  developed  during  the  first  DISA 
Capacity  Management  Workshop  as  a  starting  point.  The  Capacity  Management  Context  diagram 
developed  by  this  workshop  is  shown  on  page  4-7. 
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A-0  PERFORM  CAPACITY  MANAGEMENT 
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and  use  of  DH/IS  components.  All  of  these  CM  activities  provide  an  integrated  base  for  the  effective  performance  management  of  an  organization's 
information  systems  assets. 
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Decomposition  Diagrams 


A  decomposition  diagram  describes  the  details  of  an  activity  and  the  relationships  between  the 
activities  within  a  decomposition  level.  In  the  decomposition  process,  the  modelers  break  down  an 
activity  by  identifying  its  sub-activities.  The  ICOMs  that  interact  with  the  activities  are  depicted, 
documenting  the  activity  associations  and  the  data  needed  within  the  process.  Unlike  a  no^  tree, 
which  can  show  several  levels  of  sub-component  activities  at  once,  a  decon^sition  diagram  shows 
only  one  level  of  the  sub-activities.  Each  decomposition  diagram  further  details  the  component 
activities  of  its  parent  activity.  The  activity  modelers  check  to  ensure  that  the  activity  views  are 
consistent  from  one  level  to  the  next. 

Perform  Capacity  Management  Decomposition  Diagrams 

The  team  uses  decomposition  diagrams  to  represent  the  TO-BE  business  processes  in  Capacity 
Management.  The  models  reflect  the  consensus  of  the  Services  and  Agencies  represented  in  the 
workshop. 

The  purpose  of  this  activity  modeling  effort  is  to  discover  the  business  process  improvement 
opportunities  for  AO  Perform  Capacity  Management. 

The  core  team  identified  five  major  sub-activities  of  AO  Perform  Ci^acity  Management:  A1  Manage 
Service,  A2  Provide  Information,  A3  Manage  Performance,  A4  Plan  Ct^acity,  and  A5  Maintain 
Baseline  Models.  The  decomposition  diagrams  depicting  these  activities  begin  on  page  4-11  of  this 
report. 

While  all  five  of  the  activities  are  equally  important  to  the  process  of  Perform  Capacity  Management, 
the  time  schedule  allocated  for  this  workshop  precluded  detailed  decomposition  and  analysis  of  all  S 
major  sub-activities.  Thus,  the  group  prioritized  the  A3  Manage  Performance  and  A4  Plan 
Capacity  Activities  for  detailed  analysis  in  this  workshop.  The  criteria  for  prioritization  was  based  on 
what  the  team  intuitively  felt  would  hold  the  highest  return  on  investment  in  terms  of  improvement. 
Page  4-17  begins  the  decomposition  diagrams  for  Activity  A3  Manage  Performance.  Page  4-25 
begins  the  decomposition  diagrams  for  Activity,  A4  Plan  Capacity. 

Descriptions  of  each  activity  are  contained  in  Appendix  B,  and  the  Input,  Control,  Output,  and 
Mechanism  (ICOM)  definitions  are  contained  in  Appendix  C. 
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AO  PERFORM  CAPACITY  MANAGEMENT 
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NODE;  TITLE:  VIEWPOINT: 

A1  Manage  Service  DII/DASD(IM) 


NODE;  TITLE:  VIEWPOINT: 

A2  Provide  Information  DII/DASD(IM) 


A3  MANAGE  PERFORMANCE 
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NODE;  TITLE:  VIEWPOINT; 

A3  Manage  Performance  DII/DASD(IM) 
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NODE;  TITLE;  VIEWPOINT; 

A3 1  Measure  Performance  DII/DASD(IM) 


A311  ESTABLISH  MEASUREMENT  PLAN 
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NODE:  TITLE:  VIEWPOINT: 

A3 1 1  Establish  Measurement  Plan  DII/D ASD(IM) 


NODE:  TITLE:  VIEWPOINT: 

A32  Monitor  Performance  DII/DASD(IM) 


NODE:  TITLE:  VIEWPOINT: 

A4  Plan  Capacity  DII/DASD(IM) 


NODE:  TITLE:  VIEWPOINT: 

A41  Analyze  Capacity  DII/DASD(IM) 


A5  MAINTAIN  CAPACITY  MANAGEMENT  MODELS 
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NODE;  TITLE:  VIEWPOINT; 

A5  Maintain  Capacity  Management  Models  DII/DASD(IM) 
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Introduction  to  Data  Modeling 


The  primary  purpose  of  data  modeling  is  to  capture  the  logical  data  structures  and  business  rules 
required  to  support  an  activity's  information  needs  and  relate  them  to  data  shared  with  other 
significant  activities  or  organizations.  The  data  model  consists  of  the  following: 

Entity  -  Represents  a  set  of  real-world  objects  (people,  places,  things,  events,  etc.)  that  have 
common  characteristics.  An  entity  represents  a  class  of  real-world  objects  about  which  we 
want  to  retain  data.  An  entity  name  is  a  noun  phrase  that  describes  the  object.  An  entity 
instance  is  one  member  of  that  set  of  real-world  objects. 

Entity  Relationship  -  A  dependence  or  inter-relationship  between  entities.  The  relationships 
model  the  real-world  associations  between  persons,  places,  things,  events,  etc.  Relationships 
represent  the  business  rules  that  govern  a  process  or  organization  (e.g.,  "can  a  material 
requisition  exist  that  has  not  been  submitted  by  a  requesting  organization?"). 

The  first  step  in  developing  a  data  model  is  to  identify  potential  or  candidate  entities  (Entity  Pool). 
One  of  the  best  sources  for  identifying  candidate  entities  is  to  review  the  ICOMs  or  information  flows 
from  activity  models.  These  often  express  the  infonnation  needs  of  an  activity  that  can  be  associated 
with  entities. 

The  IDEFIX  modeling  technique  is  the  data  modeling  method  of  choice  in  the  DoD  CIM  initiative 
and  was  used  in  this  workshop.  A  more  detailed  description  of  IDEFIX  data  modeling  is  contained  in 
the  IDEF  Modeling  Reader's  Guide  (Appendix  A). 


PISA  Capacity  Management  ABA  Workshop  Data  Modeling  Activity 

The  core  team  developed  a  high  level  entity  relationship  model  for  the  DII/IS  Ciqjacity  Management 
Function  in  compliance  with  the  TO-BE  activity  model  for  CM.  The  model  was  created  in  four 
phases.  First,  a  generic  "template"  model  for  CM  was  created,  identifying  the  highest  level  entities 
for  the  CM  function  independent  of  mainframe  or  communication  networking  viewpoints.  The  entity 
pool  for  this  model  is  presented  on  page  4-33.  The  model  is  shown  on  page  4-34,  and  the  associated 
business  rules  are  described  on  pages  4-35  through  4-38.  The  entities  are  defined  in  Appendix  D. 

In  the  second  phase,  the  data  entities  specific  to  the  Mainffame/Host  (centralized  processing) 
environment  were  identified,  defined,  and  related  in  an  entity  relationship  model.  The  Entity  Pool 
for  the  Mainframe/Host  Environment  is  presented  on  page  4-39.  The  Mainframe/Host 
Environment  Entity  Pool  Matrix  is  presented  in  Table  4-1,  on  pages  4-40  through  4-41.  The 
corresponding  DII/IS  Capacity  Management  Mainframe/Host  Entity  Relationship  Model  is 
presented  on  page  4-42,  and  the  Business  Rules  for  Mainframe/Host  Environment  are  shown  on 
page  4-43  through  4-48.  The  Entity  Definitions  are  located  in  Appendix  D. 
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In  the  third  phase,  the  data  entities  specific  to  the  Communications  Network  (distributed  processing) 
environment  were  identified,  defined,  and  related  in  an  entity  relationship  model.  The  entity  pool  for 
Communications  Network  is  presented  on  page  4-49.  The  Communications  Network  Entity  Pool 
Matrix  is  presented  in  Table  4-2  on  page  4-SO.  The  corresponding  entity  relationship  diagram  is 
presented  on  page  4-51,  and  the  associated  business  rtiles  are  shown  on  page  4-52  though  4-56.  The 
entities  are  defined  in  i^^jpendix  D. 

In  phase  four,  the  two  specific  data  views  for  Mainffame/Host  and  Communications  Network  are 
integrated  into  the  phase  1  generic  ’template”  model  to  create  the  DII/IS  CM  Entity  Relationship 
model,  page  4-57. 


High  Level  Entity  Pool  for  Perform  Capacity  Management  Function  Generic 
■Template" 

The  following  high  level  classes  of  data  were  selected  for  the  Generic  ”Ten:q>late'’  Data  Models.  The 
specified  entities  are  independent  of  mainframe  and  communications,  network  environments. 

APPLICATION-FUNCTIONAL-REQUIREMENT 

APPLICATION-PROCESSING-REQUIREMENT 

BASELINE-MODEL 

BENCHMARK 

CHANGE-REQUEST 

COMPONENT 

ENVIRONMENT-SUPPORT-SYSTEM 

MODELING-BENCHMARK-RESULT 

PERFORMANCE-LOG-DATA 

PERFORMANCE-PREDICTION-DATA 

SECURITY-SYSTEM 

STAND  ARD-PERFORMANCE-METRIC-SLO 
SYSTEM-EXECUTION-ENVIRONMENT 
USER-WORKLOAD-SCENARIO 
WORKLOAD-CHARACTERIZATION 
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Business  Rules  for  Perform  Capacity  Manaygment  Function  Generic  ’Template** 


Every  APPLICATION-FUNCTIONAL-REQUIREMENT 

always  sets  requirements  for  zero,  one  or  many  WORKLOAD-CHARACTERIZATION 

Every  APPLICATION-FUNCTIONAL-REQUIREMENT 
always  sets  requirements  for  zero,  one  or  many 
APPLICATION-PROCESSING-REQUIREMENT 

Every  APPLICATION-PROCESSING-REQUIREMENT 

always  is  recommended  for  change  by  MODELING-BENCHMARK-RESULT 

Every  APPLICATION-PROCESSING-REQUIREMENT 

always  is  guided  by  zero,  one  or  many  WORKLOAD-CHARACTERIZATION 

Every  APPLICATION-PROCESSING-REQUIREMENT 

always  are  set  by  zero,  one  or  many  APPLICATION-FUNCTIONAL-REQUIREMENT 

Every  APPLICATION-PROCESSING-REQUIREMENT 

always  incorporates  zero,  one  or  many  BENCHMARK 

Every  APPLICATION-PROCESSING-REQUIREMENT 

always  is  limited  by  zero,  one  or  many  SYSTEM-EXECUTION-ENVIRONMENT 

Every  APPLICATION-PROCESSING-REQUIREMENT 
always  specifies  zero,  one  or  many  COMPONENT 

Every  BASELINE-MODEL 

always  is  modified  by  zero,  one  or  many  CHANGE-REQUEST 
Every  BASELINE-MODEL 

always  is  described  by  zero,  one  or  many  COMPONENT 
Every  BASELINE-MODEL 

always  generates  zero,  one  or  many  PERFORMANCE-PREDICTION-DATA 
Every  BASELINE-MODEL 

always  generates  zero,  one  or  many  MODELING-BENCHMARK-RESULT 
Every  BASELINE-MODEL 

always  is  modified  by  zero,  one  or  many  MODELING-BENCHMARK-RESULT 
Every  BASELINE-MODEL 

always  is  used  by  zero,  one  or  many  STANDARD-PERFORMANCE-METRIC-SLO 
Every  BASELINE-MODEL 

always  describes  zero,  one  or  many  SYSTEM-EXECUTION-ENVIRONMENT 
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Every  BENCHMARK 

always  generates  zero,  one  or  many  MODELING-BENCHMARK-RESULT 
Every  BENCHMARK 

always  generates  zero,  one  or  many  PERFORMANCE-LOG-DATA 
Every  BENCHMARK 

always  is  incorporated  in  zero,  one  or  many  APPLICATION-PROCESSING-REQUIREMENT 
Every  BENCHMARK 

always  is  executed  on  zero,  one  or  many  SYSTEM-EXECUTION-ENVIRONMENT 
Every  BENCHMARK 

always  modifies  zero,  one  or  many  CHANGE-REQUEST 
Every  BENCHMARK 

always  uses  zero,  one  or  many  STANDARD-PERFORMANCE-METRIC-SLO 

Every  CHANGE-REQUEST 

always  modifies  zero,  one  or  many  COMPONENT 

Every  CHANGE-REQUEST 

always  is  modified  by  zero,  one  or  many  BENCHMARK 

Every  CHANGE-REQUEST 

always  modifies  zero,  one  or  many  BASELINE-MODEL 

Every  CHANGE-REQUEST 

always  modifies  zero,  one  or  many  SYSTEM-EXECUTION-ENVIRONMENT 
Every  COMPONENT 

always  is  specified  by  zero,  one  or  many  APPLICATION-PROCESSING-REQUIREMENT 
Every  COMPONENT 

always  describes  zero,  one  or  many  BASELINE-MODEL 
Every  COMPONENT 

always  is  modified  by  zero,  one  or  many  CHANGE-REQUEST 
Every  COMPONENT 

always  is  reconunended  for  change  by  zero,  one  or  many  MODELING-BENCHMARK- 
RESULT 

Every  COMPONENT 

always  is  configured  by  zero,  one  or  many  SYSTEM-EXECUTION-ENVIRONMENT 

Every  ENVIRONMENTAL-SUPPORT-SYSTEM 

is  a  SYSTEM-EXECUTION-ENVIRONMENT 
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Every  MODELING-BENCHMARK-RESULT 

always  is  generated  by  zero,  one  or  many  BASELINE-MODEL 

Every  MODELING-BENCHMARK-RESULT 

always  is  generated  by  zero,  one,  or  many  BENCHMARK 

Every  MODELING-BENCHMARK-RESULT 

always  recommends  change  to  APPLICATION-PROCESSING-REQUIREMENT 

Every  MODELING-BENCHMARK-RESULT 

always  recommends  change  to  zero,  one,  or  many  WORKLOAD-CHARACTERIZATION 

Every  MODELING-BENCHMARK-RESULT 

always  recommends  change  to  zero.  one.  or  many  COMPONENT 

Every  MODELING-BENCHMARK-RESULT 

always  is  used  by  zero,  one  or  many  PERFORMANCE-LOG-DATA 

Every  MODELING-BENCHMARK-RESULT 

always  is  modified,  changed  by  zero,  one  or  many  STANDARD-PERFORMANCE-METRIC- 
SLO 

Every  MODELING-BENCHMARK-RESULT 

always  recommends  change  to  zero,  one.  or  many  SYSTEM-EXECUTION-ENVIRONMENT 

Every  MODELING-BENCHMARK-RESULT 

always  is  used  by  zero,  one,  or  many  PERFORMANCE-PREDICTION-DATA 

Every  PERFORMANCE-LOG-DATA 

always  uses  zero,  one,  or  many  MODELING-BENCHMARK-RESULT 

Every  PERFORMANCE-LOG-DATA 

always  is  con^)ared  against  zero,  one,  or  many  PERFORMANCE-PREDICTION-DATA 
Every  PERFORMANCE-LOG-DATA 

always  is  compared  against  zero,  one,  or  many  STANDARD-PERFORMANCE-METRIC- 
SLO 

Every  PERFORMANCE-LOG-DATA 

always  is  generated  by  zero,  one,  or  many  BENCHMARK 

Every  PERFORMANCE-PREDICTION-DATA 

always  generates  zero,  one  or  many  BASELINE-MODEL 

Every  PERFORMANCE-PREDICTION-DATA 

always  is  compared  against  zero,  one  or  many  STANDARD-PERFORMANCE-METRIC-SLO 

Every  PERFORMANCE-PREDICTION-DATA 

always  uses  zero,  one  or  many  MODELING-BENCHMARK-RESULT 
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Every  PERFORMANCE-PREDICTION-DATA 

always  is  compared  against  zero,  one  or  many  PERFORMANCE-LOG-DATA 


Every  SECURITY-SYSTEM 

is  a  SYSTEM-EXECUTION-ENVIRONMENT 

Every  STANDARD-PERFORMANCE-METRIC-SLO 

always  is  used  by  zero,  one  or  many  BENCHMARK 

Every  STANDARD-PERFORMANCE-METRIC-SLO 

always  is  compared  against  zero,  one  or  many  PERFORMANCE-LOG-DATA 

Every  STANDARD-PERFORMANCE-METRIC-SLO 

always  modifies,  changes  zero,  one  or  many  MODELING-BENCHMARK-RESULT 

Every  STANDARD-PERFORMANCE-METRIC-SLO 

always  uses  zero,  one  or  many  BASELINE-MODEL 

Every  STANDARD-PERFORMANCE-METRIC-SLO 

always  is  compared  against  zero,  one,  or  many  PERFORMANCE-PREDICTION-DATA 

Every  SYSTEM-EXECUTION-ENVIRONMENT 

always  configures  zero,  one  or  many  COMPONENT 

Every  SYSTEM-EXECUTION-ENVIRONMENT 

always  limits  zero,  one  or  many  APPLICATION-PROCESSING-REQUIREMENT 

Every  SYSTEM-EXECUTION-ENVIRONMENT 

always  is  described  in  zero,  one  or  many  BASELINE  MODEL 

Every  SYSTEM-EXECUTION-ENVIRONMENT 

always  is  modified  by  zero,  one  or  many  CHANGE-REQUEST 

Every  SYSTEM-EXECUTION-ENVIRONMENT 

always  is  recommended  for  change  by  zero,  one  or  many 
MODELING-BENCHMARK-RESULT 

Every  SYSTEM-EXECUTION-ENVIRONMENT 

always  is  executed  by  zero,  one  or  many  BENCHMARK 

Every  WORKLOAD-CHARACTERIZATION 

always  is  recommended  by  change  by  zero,  one  or  many  MODELING-BENCHMARK- 
RESULT 

Every  WORKLOAD-CHARACTERIZATION 

always  has  its  requirements  set  by  zero,  one,  or  many  APPLICATION-FUNCTIONAL- 
REQUIREMENT 

Every  WORKLOAD-CHARACTERIZATION 

always  guides  zero,  one  or  many  APPLICATION-PROCESSING-REQUIREMENT 
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Entity  Porf  for  Mainframe/Host  Environment 

COMMUNICATION-LINK  (MEDIA) 

COMMUNICATION-NETWORK-COMPONENT 

END-SYSTEM-PRESENTATION-RQMT 

MAINFRAME/HOST 

MAINFRAME-OPERATING-SYSTEM 

NETWORK 

PC-CLIENT-WORKSTATION-TERMINAL 
PRIMARY-STORAGE  (MAIN  MEMORY) 

PROTOCOL 

SECONDARY-STORAGE  (DASD  &  TAPE) 
SECURITY-INFRASTRUCTURE 
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MAINFRAME  H  SECURITY-  PROTOCOL  END  SYSTEM  COMMUNICATION-  COMMUNICATION-  NETWORK 

COMPONENT  I  INFRASTRUCTURE  PRESENTATION  RQMT  NETWORK-  LINK  (MEDIA) 
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SECONDARY-STORAGE  (DASD  A  TAPE)  ^  » ipecified  bjAtptcifiei  ^  END-SYSTEM-PRESENT ATION-RQMT  ^ _ i>  •pecifkd  byMpecifiei _ J  PRIMARY-STORAGE 


Business  Rules  for  Mainframe/Host  Environment 


Every  PROTOCOL 

always  is  incorporated  in  zero,  one,  or  many  PROTOCOL 

Every  SECURITY-INFRASTRUCTURE 

always  influence  selection  and  operation  of  zero,  one,  or  many 
COMMUNICATION-NETWORK-COMPONENT 

Every  SECURITY-INFRASTRUCTURE 

always  influences  zero,  one,  or  many  COMMUNICATION-LINK  (MEDIA) 

Every  SECURITY-INFRASTRUCTURE 

adways  is  provided  by  zero,  one,  or  many  NETWORK 

Every  SECURITY-INFRASTRUCTURE 

always  provides  guidelines  for  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 

Every  COMMUNICATION-LINK  (MEDIA) 

always  includes  zero,  one,  or  many  NETWORK 

Every  COMMUNICATION-NETWORK-COMPONENT 

always  is  provided  connectivity  for  zero,  one,  or  many  NETWORK 

Every  COMMUNICATION-NETWORK-COMPONENT 

always  physically  connects  zero,  one,  or  many  COMMUNICATION-LINK  (MEDIA) 

Every  END-SYSTEM-PRESENTATION-RQMT 
always  influences  selection  of  zero,  one,  or  many 
COMMUNICATION-NETWORK-COMPONENT 

Every  END-SYSTEM-PRESENTATION-RQMT 

adways  influences  zero,  one,  or  many  COMMUNICATION-LINK  (MEDIA) 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  is  influenced  by  zero,  one,  or  many  NETWORK 

Every  MAINFRAME-OPERATING-SYSTEM 

always  interfaces  to  zero,  one,  or  many  COMMUNICATION-NETWORK-COMPONENT 

Every  MAINFRAME-OPERATING-SYSTEM 

always  interfaces  zero,  one,  or  many  PROTOCOL 

Every  MAINFRAME-OPERATING-SYSTEM 

always  is  screened  for  access  by  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 
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Every  MAINFRAME-OPERATING-SYSTEM 

always  manage  and  execute  prog  using  zero,  one,  or  many  PRIMARY-STORAGE  (MAIN 
MEMORY) 

Every  MAINFRAME-OPERATING-SYSTEM 

always  provides  access,  retrieval  and  management  of  zero,  one,  or  many 
SECONDARY-STORAGE  (DASD  &  TAPE) 

Every  MAINFRAME-OPERATING-SYSTEM 

aJways  support  comm,  software  for  zero,  one,  or  many  NETWORK 

Every  MAINFRAME/HOST 

^ways  executes  program  using  zero,  one,  or  many  PRIMARY-STORAGE  (MAIN 
MEMORY) 

Every  MAINFRAME/HOST 

always  implements  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 
Every  MAINFRAME/HOST 

always  is  provide  connectivity  for  info  transport  by  zero,  one,  or  many  NETWORK 

Every  MAINFRAME/HOST 

sdways  is  provided  an  interface  to  zero,  one,  or  many 
COMMUNICATION-NETWORK-COMPONENT 

Every  MAINFRAME/HOST 

always  operates  using  zero,  one,  or  many  MAINFRAME-OPERATING-SYSTEM 
Every  MAINFRAME/HOST 

always  store  and  retrieves  info  on  zero,  one,  or  many  SECOND ARY-STORAGE  (DASD  & 
TAPE) 

Every  MAINFRAME/HOST 

always  uses  zero,  one,  or  many  COMMUNICATION-LINK  (MEDIA) 

Every  MAINFRAME/HOST 

always  uses  zero,  one,  or  many  PROTOCOL 

Every  PC-CLIENT-WORKSTATION-TERMINAL 

always  is  influenced  by  zero,  one,  or  many  END-SYSTEM-PRESENT ATION-RQMT 

Every  PC-CLIENT-WORKSTATION-TERMINAL 
always  is  provided  an  interface  to  zero,  one,  or  many 
COMMUNICATION-NETWORK-COMPONENT 

Every  PC-CLIENT-WORKSTATION-TERMINAL 

aJways  is  provided  info  transport  for  zero,  one,  or  many  NETWORK 
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Every  PC-CLIENT-WORKSTATION-TERMINAL 

always  is  screened  for  access  by  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  PC-CLIENT-WORKSTATION-TERMINAL 

adways  sends  service  request  to  zero,  one,  or  many  MAINFRAME/HOST 

Every  PC -CLIENT- WORKSTATION-TERMINAL 
sdways  uses  zero,  one,  or  many  PROTOCOL 

Every  PC-CLIENT-WORKSTATION-TERMINAL 

always  uses  zero,  one,  or  many  COMMUNICATION-LINK  (MEDIA) 

Every  PRIMARY-STORAGE  (MAIN  MEMORY) 

always  is  specified  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 

Every  PRIMARY-STORAGE  (MAIN  MEMORY) 
always  is  used  by  zero,  one,  or  many  PROTOCOL 

Every  PRIMARY-STORAGE  (MAIN  MEMORY) 

always  is  used  by  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  PRIMARY-STORAGE  (MAIN  MEMORY) 

always  uses  zero,  one,  or  many  COMMUNICATION-NETWORK-COMPONENT 

Every  PROTOCOL 

always  has  its  suite  determined  by  za:o,  one,  or  many 
COMMUNICATION-NETWORK-COMPONENT 

Every  PROTOCOL 

always  is  implemented  by  zero,  one,  or  many  NETWORK 
Every  PROTOCOL 

aJways  is  influenced  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 

Every  SECONDARY-STORAGE  (DASD  &  TAPE) 

always  is  specified  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 

Every  SECONDARY-STORAGE  (DASD  &  TAPE) 

always  is  used  by  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  SECONDARY-STORAGE  (DASD  &  TAPE) 

always  is  used  by  zero,  one,  or  many  COMMUNICATION-NETWORK-COMPONENT 

Every  SECURITY-INFRASTRUCTURE 

always  is  implemented  by  zero,  one,  or  many  MAINFRAME/HOST 

Every  SECURITY-INFRASTRUCTURE 

always  controls  access  for  zero,  one,  or  many  PC-CLIENT-WORKSTATION-TERMINAL 
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Every  SECURITY-INFRASTRUCTURE 

always  controls  access  to  zero,  one,  or  many  MAINFRAME-OPERATING-SYSTEM 

Every  SECURITY-INFRASTRUCTURE 

adways  uses  zero,  one,  or  many  PRIMARY-STORAGE  (MAIN  MEMORY) 

Every  SECURITY-INFRASTRUCTURE 

always  uses  zero,  one,  or  many  SECOND ARY-STORAGE  (DASD  &  TAPE) 

Every  COMMUNICATION-LINK  (MEDIA) 

always  implements  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  COMMUNICATION-LINK  (MEDIA) 

always  is  influenced  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 

Every  COMMUNICATION-LINK  (MEDIA) 

always  is  connected  by  zero,  one,  or  many  COMMUNICATION-NETWORK-COMPONENT 

Every  COMMUNICATION-LINK  (MEDIA) 

always  is  used  by  zero,  one,  or  many  MAINFRAME/HOST 

Every  COMMUNICATION-LINK  (MEDIA) 

always  is  used  by  zero,  one,  or  many  PC-CLIENT-WORKSTATION-TERMINAL 

Every  COMMUNICATION-NETWORK-COMPONENT 

adways  determines  suite  of  zero,  one,  or  many  PROTCX^OL 

Every  COMMUNICATION-NTTWORK-COMPONENT 

always  provide  selection  crit.  for  zero,  one,  or  many  SECURTT-  INFRASTRUCTURE 

Every  COMMUNICATION-NETWORK-COMPONENT 

always  is  selected  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 

Every  COMMUNICATION-NETWORK-COMPONENT 

always  is  interfaced  to  zero,  one,  or  many  MAINFRAME-OPERATING-SYSTEM 

Every  COMMUNICATION-NETWORK-COMPONENT 

always  provides  interface  to  zero,  one,  or  many  MAINFRAME/HOST 

Every  COMMUNICATION-NETWORK-COMPONENT 

always  provides  interface  to  zero,  one,  or  many  PC-CLIENT-WORKSTATION-TERMINAL 

Every  COMMUNICATION-NETWORK-COMPONENT 

always  uses  zero,  one,  or  many  SECOND  ARY-STORAGE  (DASD  &  TAPE) 

Every  COMMUNICATION-NETWORK-COMPONENT 

always  is  used  by  zero,  one,  or  many  PRIMARY-STORAGE  (MAIN  MEMORY) 
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Every  END-SYSTEM-PRESENTATION-RQMT 

always  influences  selection  of  zero,  one,  or  many  PC-CLIENT- WORKSTATION-TERMINAL 

Every  END-SYSTEM-PRESENTATION-RQMT 

aiways  provides  selection  criteria  for  zero,  one,  or  many  PROTOCOL 

Every  END-SYSTEM-PRESENTATION-RQMT 

adways  specifies  zero,  one,  or  many  PRIMARY-STORAGE  (MAIN  MEMORY) 

Every  END-SYSTEM-PRESENTATION-RQMT 

adways  is  specified  by /specifies  zero.  one.  or  many  SECOND  ARY-STORAGE  (DASD  & 
TAPE) 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  adheres  to  guidelines  for  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  MAINFRAME-OPERATING-SYSTEM 

always  enables  operation  of  zero,  one,  or  many  MAINFRAME/HOST 

Every  MAINFRAME/HOST 

always  provittes  services  for  zero,  one,  or  many  PC-CLIENT-WORKSTATION-TERMINAL 
Every  NETWORK 

always  is  an  element  of  zero,  one,  or  many  COMMUNICATION-LINK  (MEDIA) 

Every  NETWORK 

always  implements  zero,  one,  or  many  PROTOCOL 
Every  NETWORK 

always  affects  performance  and  design  of  zero,  one,  or  many 
END-SYSTEM-PRESENTATION-RQMT 

Every  NETWORK 

adways  provides  connect  for  zero,  one,  or  many  MAINFRAME/HOST 
Every  NETWORK 

adways  provides  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 
Every  NETWORK 

always  provides  connectivity  for  zero,  one,  or  many 
COMMUNICATION-NETWORK-COMPONENT 

Every  NETWORK 

always  provides  connectivity  for  zero,  one,  or  many 
PC-CLIENT-WORKSTATION-TERMINAL 


Every  NETWORK 

always  has  its  comm,  software  supported  by  zero.  one.  or  many 
MAINFRAME-OPERATING-SYSTEM 

Every  PRIMARY-STORAGE  (MAIN  MEMORY) 

always  is  used  for  execution  of  program  by  zero.  one.  or  many  MAINFRAME/HOST 

Every  PRIMARY-STORAGE  (MAIN  MEMORY) 

always  is  managed  and  system  execution  by  zero.  one.  or  many 
MAINFRAME-OPERATING-SYSTEM 

Every  PROTOCOL 

always  is  incorporated  in  zero.  one.  or  many  SECURITY-INFRASTRUCTURE 
Every  PROTOCOL 

always  is  interfaced  by  zero.  one.  or  many  MAINFRAME-OPERATING-SYSTEM 
Every  PROTOCOL 

always  uses  zero.  one.  or  many  PRIMARY-STORAGE  (MAIN  MEMORY) 

Every  PROTOCOL 

always  is  used  by  zero.  one.  or  many  PC -CLIENT-WORKSTATION-TERMINAL 
Every  PROTOCOL 

always  is  used  by  zero.  one.  or  many  MAINFRAME/HOST 

Every  SECONDARY-STORAGE  (DASD  &  TAPE) 

always  is  managed  by  zero.  one.  or  many  MAINFRAME-OPERATING-SYSTEM 

Every  SECONDARY-STORAGE  (DASD  &  TAPE) 

always  is  used  to  store  and  retrieve  info  by  zero.  one.  or  many  MAINFRAME/HOST 
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Entity  Pool  for  Communications  Network  Environment 

COMMUNICATIONS-LINK  (MEDIA) 

COMMUNICATIONS-NETWORK-COMPONENT 

END-SYSTEM-PRESENTATION-RQMT 

NETWORK 

PC-CLIENT-WORKSTATION-TERMINAL 
PRIMARY-STORAGE  (INTERNAL  MEMORY) 

PROTOCOL 

SECONDARY-STORAGE  (WORKSTATION  HARD  DISK) 

SECURITY-INFRASTRUCTURE 

SERVER 
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Table  4-2.  Communication/Networks  Environment  Entity  Pool  Matrix. 


Business  Rules  for  Communications  Network  Environment 


Every  NETWORK 

sQways  is  provided  connectivity  by  zero,  one,  or  many 
COMMUNICATIONS-NETWORK-COMPONENT 

Every  SECURITY-INFRASTRUCTURE 

always  implements  zero,  one,  or  many  SERVER 

Every  SECURITY-INFRASTRUCTURE 

always  influences  zero,  one,  or  many  COMMUNICATIONS-NETWORK-COMPONENT 
Every  SECURITY-INFRASTRUCTURE 

always  is  influenced  by  zero,  one,  or  many  COMMUNICATIONS-LINK  (MEDIA) 

Every  SECURITY-INFRASTRUCTURE 

always  is  provided  by  zero,  one,  or  many  NETWORK 

Every  SECURITY-INFRASTRUCTURE 

always  is  screened  for  access  by  zero,  one,  or  many 
PC-CLIENT-WORKSTATION-TERMINAL 

Every  SECURITY-INFRASTRUCTURE 

always  is  used  by  zero,  one,  or  many  PRIMARY-STORAGE  (INTERNAL  MEMORY) 
Every  SECURITY-INFRASTRUCTURE 

always  provides  guidelines  for  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 
Every  SERVER 

always  executes  program  using  zero,  one,  or  many  PRIMARY-STORAGE  (INTERNAL 
MEMORY) 

Every  SERVER 

always  is  influenced  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 
Every  SERVER 

always  is  provided  an  interface  to  zero,  one,  or  many 
COMMUNICATIONS-NETWORK-COMPONENT 

Every  SERVER 

sdways  is  provided  info  transport  connectivity  by  zero,  one,  or  many  NETWORK 
Every  SERVER 

always  provides  service  for  zero,  one,  or  many  PC-CLIENT-WORKSTATION-TERMINAL 
Every  SERVER 

always  uses  zero,  one,  or  many  PROTOCOL 
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Every  SERVER 

always  uses  zero,  one,  or  many  COMMUNICATIONS-LINK  (MEDIA) 

Every  PROTOCOL 

adways  has  its  suite  determined  by  zero,  one,  or  many 
COMMUNICATIONS-NETWORK-COMPONENT 

Every  PROTOCOL 

always  is  implemented  by  zero,  one,  or  many  NETWORK 
Every  PROTOCOL 

idways  is  influenced  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 
Every  PROTOCOL 

always  uses  zero,  one,  or  many  PC -CLIENT-WORKSTATION-TERMINAL 

Every  COMMUNICATIONS-LINK  (MEDIA) 

always  is  an  element  of  zero,  one,  or  many  NETWORK 

Every  COMMUNICATIONS-LINK  (MEDIA) 
always  physically  connects  zero,  one,  or  many 
COMMUNICATIONS-NETWORK-COMPONENT 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  affects  performance  and  design  of  zero,  one,  or  many  NETWORK 

Every  END-SYSTEM-PRESENTATION-RQMT 
always  influences  selection  of  zero,  one,  or  man> 
COMMUNICATIONS-NETWORK-COMPONENT 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  is  influenced  by  zero,  one,  or  many  COMMUNICATIONS-LINK  (MEDIA) 

Every  PC-CLIENT-WORKSTATION-TERMINAL 

aJways  is  influenced  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 

Every  PC-CLIENT-WORKSTATION-TERMINAL 
always  is  provided  an  interface  to  zero,  one,  or  many 
COMMUNICATIONS-NETWORK-COMPONENT 

Every  PC-CLIENT-WORKSTATION-TERMINAL 

always  is  provided  info  transport  by  zero,  one,  or  many  NETWORK 

Every  PC-CLIENT-WORKSTATION-TERMINAL 

always  uses  zero,  one,  or  many  COMMUNICATIONS-LINK  (MEDIA) 

Every  PRIMARY-STORAGE  (INTERNAL  MEMORY) 

always  is  specified  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 
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Every  PRIMARY-STORAGE  (INTERNAL  MEMORY) 

always  is  used  by  zero,  one  or  many  COMMUNICATIONS-NETWORK-COMPONENT 

Every  PRIMARY-STORAGE  (INTERNAL  MEMORY) 

aJways  is  used  for  execution  of  program  by  zero.  one.  or  many 
PC-CLIENT-WORKSTATION-TERMINAL 

Every  PRIMARY-STORAGE  (INTERNAL  MEMORY) 
always  uses  zero.  one.  or  many  PROTOCOL 

Every  SECONDARY-STORAGE  (WORKSTATION  HARD  DISK)) 

always  is  specified  by  zero.  one.  or  many  END-SYSTEM-PRESENTATION-RQMT 

Every  SECONDARY-STORAGE  (WORKSTATION  HARD  DISK)) 

always  is  used  by  zero.  one.  or  many  SECURITY-INFRASTRUCTURE 

Every  SECONDARY-STORAGE  (WORKSTATION  HARD  DISK)) 

always  is  used  by  zero.  one.  or  many  COMMUNICATIONS-NETWORK-COMPONENT 

Every  SECONDARY-STORAGE  (WORKSTATION  HARD  DISK)) 
always  is  used  to  store,  retrieve  info  by  zero.  one.  or  many  SERVER 

Every  SECONDARY-STORAGE  (WORKSTATION  HARD  DISK)) 

always  uses  zero,  one,  or  many  PC-CLIENT-WORKSTATION-TERMINAL 

Every  NETWORK 

always  is  influenced  by  zero,  one,  or  many  END-SYSTEM-PRESENTATION-RQMT 
Every  NETWORK 

aJways  comprises  zero,  one,  or  many  COMMUNICATIONS-LINK  (MEDIA) 

Every  NETWORK 

adways  implements  zero,  one,  or  many  PROTOCOL 
Every  NETWORK 

always  provide  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 
Every  NETWORK 

always  provides  info  connects  zero,  one,  or  many 
PC-CLIENT-WORKSTATION-TERMINAL 

Every  NETWORK 

always  provide  info  connects  zero,  one,  or  many  SERVER 
Every  SECURITY-INFRASTRUCTURE 

always  uses  zero,  one,  or  many  SECONDARY-STORAGE  (WORKSTATION  HARD  DISK)) 
Every  SERVER 

always  is  implemented  by  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 
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Every  SERVER 

always  stores,  retrieves  info  on  zero,  one,  or  many  SECONDARY-STORAGE 
(WORKSTATION  HARD  DISK)) 

Every  PROTOCOL 

always  comprises  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 
Every  PROTOCOL 

always  is  used  by  zero,  one,  or  many  SERVER 
Every  PROTOCOL 

always  is  used  by  zero,  one,  or  many  PRIMARY-STORAGE  (INTERNAL  MEMORY) 

Every  COMMUNiCATIONS-LINK  (MEDIA) 

always  influences  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  COMMUNICATIONS-LINK  (MEDIA) 

always  uses  zero,  one,  or  many  END-SYSTEM-PRESENT ATION-RQMT 

Every  COMMUNICATIONS-LINK  (MEDIA) 
always  is  used  by  zero,  one,  or  many  SERVER 

Every  COMMUNICATIONS-LINK  (MEDIA) 

always  is  used  by  zero,  one,  or  many  PC-CLIENT-WORKSTATION-TERMINAL 

Every  COMMUNICATIONS-NETWORK-COMPONENT 

always  determines  a  suite  of  zero,  one,  or  many  PROTOCOL 

Every  COMMUNICATIONS-NETWORK-COMPONENT 

always  is  selected  by  zero,  one,  or  many  END-SYSTEM-PRESENT  ATION-RQMT 

Ev;ry  COMMUNICATIONS-NETWORK-COMPONENT 

always  implements  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  COMMUNICATIONS-NETWORK-COMPONENT 
always  provides  interface  to  zero,  one,  or  many  SERVER 

Every  COMMUNICATIONS-NETWORK-COMPONENT 

always  provides  interface  to  zero,  one,  or  many  PC -CLIENT-WORKSTATION-TERMINAL 

Every  COMMUNICATIONS-NETWORK-COMPONENT 

always  provides  connectivity  for  zero,  one,  or  many  NETWORK 

Every  COMMUNICATIONS-NETWORK-COMPONENT 

always  uses  zer(  me,  or  many  PRIMARY-STORAGE  (INTERNAL  MEMORY) 

Every  COMMUNIC  lONS-NETWORK-COMPONENT 

always  uses  zero,  one,  or  many  SECONDARY-STORAGE  (WORKSTATION  HARD  DISK)) 


Every  COMMUNICATIONS-NETWORK-COMPONENT 

always  is  connected  by  zero,  one,  or  many  COMMUNICATIONS-LINK  (MEDIA) 

Every  END-SYSTEM-PRESENTATION-RQMT 
always  influences  selection  of  zero,  one,  or  many 
PC-CUENT-WORKSTATION-TERMINAL 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  influences  configuration  of  zero,  one,  or  many  SERVER 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  provides  selection  criteria  for  zero,  one,  or  many  PROTOCOL 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  specifies  zero,  one,  or  many  PRIMARY-STORAGE  (INTERNAL  MEMORY) 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  specifies  zero,  one,  or  many  SECONDARY-STORAGE  (WORKSTATION 
HARD  DISK) 

Every  END-SYSTEM-PRESENTATION-RQMT 

always  adheres  to  guidelines  for  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  PC-CLIENT-WORKSTATION-TERMINAL 

always  controls  access  for  zero,  one,  or  many  SECURITY-INFRASTRUCTURE 

Every  PC-CLIENT-WORKSTATION-TERMINAL 
always  sends  request  to  zero,  one,  or  many  SERVER 

Every  PC-CLIENT-WORKSTATION-TERMINAL 
always  is  used  by  zero,  one,  or  many  PROTOCOL 

Every  PRIMARY-STORAGE  (INTERNAL  MEMORY) 

always  is  used  for  execution  of  program  by  zero,  one,  or  many  SERVER 

Every  PRIMARY-STORAGE  (INTERNAL  MEMORY) 

always  uses  zero,  one,  or  many  SECURITY  insert  template  model 
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The  Dn/IS  components  referenced  in  A3. 1.1.1,  Determine  Components  to  be  Measured  can  be 
grouped  into  three  major  categories.  Mainframe  (related  to  centralized  processing  environments), 
Communications  Network  (related  to  distributed  processing  environments),  and  Configurations. 
Mainframe  components  are  organized  into  the  following  subcategories  (see  A3. 1.1.1  node  tree): 

A3 . 1 . 1 . 1 . 1 . 1  Mainframe  Host  (CPU/Operating  System) 

A3. 1 . 1 . 1 . 1 .2  Primary  Storage  (Main  Memory) 

A3. 1.1. 1.1.3  Secondary  Storage  (DASD  &  Tape) 

A3 . 1 . 1 . 1 . 1 .4  PC/Client/Workstationn'emiinal  (CPU/Operating  System) 

A3.1.1.1.1.5  Front  End  (UO) 

A3.1.1.1.1.6  I/O  Channel(s) 

A3. 1.1. 1.1.7  Peripherals 

Communications  Network  ConqMnents  were  segmented  as  follows  (see  A3. 1.1. 2  node  tree): 

A3. 1.1. 1.2.1  Server  (CPU/Operating  System) 

A3. 1.1. 1.2. 2  PC/Client/Workstation/Terminal  (CPU/Operating  System) 

A3. 1.1. 1.2. 3  Primary  Storage  (Internal  Memory) 

A3 . 1 . 1 . 1 .2 .4  Secondary  Storage  (Workstation  Hard  Disk  Storage) 

A3. 1 . 1 . 1 .2.5  Channels  (Circuits) 

A3. 1.1. 1.2.6  Gateways,  Routers,  Bridges 
A3. 1.1. 1.2.7  Hubs,  Ports,  Modems 

A3 . 1 . 1 . 1 .2 . 8  Communication  Links  (Media)/Network/Bus  Topology 

Configurations,  A3. 1.1. 1.3  were  not  further  decon^wsed  in  this  workshop. 

The  performance  metrics  referenced  in  A3. 1.1. 2,  Establish  Performance  Metrics,  were  organized  into 
the  following  broad  categories  (see  A3. 1.1. 2  node  tree): 

A3 . 1 . 1 .2. 1  Capacity  (Reserve,  Available,  Planned) 

A3. 1.1. 2. 2  Contention 

A3 . 1 . 1 .2.3  Error  Rates/Detection/Correction 

A3. 1.1. 2.4  Response  Time 

A3. 1.1. 2.5  Througl^ut 

A3. 1.1. 2. 6  Utilization 

A3. 1.1. 2.7  Workload 

Definitions  for  these  metric  categories  are  found  in  Appendix  E,  Terms. 

The  components  were  compared  against  the  performance  metric  categories  to  determine  the  specific 
measurements  needed  for  each  component  metric  combination.  The  results  of  this  analysis  are 
presented  in  Tables  4-3  and  4-4,  on  pages  4-59  and  4-60  respectively. 
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A3.1.1.1  A3,1.IJ!  EsUblUh  Pcffomance  Metrics 

Determine  Components  lo  be 

Measared 
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Table  4-3.  Establish  Performance  Metrics  for  Mainframe/Host  Environment. 


A3.1.1.1  A3.1.U  EyUblish  Pcrfoniuiiicc  MHric$ 

Determine  Components  to  be 
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Table  4-4.  Establish  Performance  Metrics  for  Communications  Network  Environment. 


The  activity  decomposition  models  for  the  TO-BE  CM  Function  were  analyzed  to  determine  the 
primary  reports  generated  from  each  activity.  Twenty-five  reports  were  identified  and  related  to  their 
source  activities  and  the  functional  DII/IS  areas  they  address.  The  lepotts  are  defined  in  Appendix  C, 
ICOM  Definitions.  A  representation  of  the  discovered  reporting  requirements  and  their  relationships  to 
source  activities  and  functional  areas  is  presented  in  table  4-S,  on  page  4-62. 

The  reporting  requirements  were  selected  to  represent  a  standardized  set  of  reports  applicable  to  both 
the  Mainframe/Host  (centralized  processing)  and  Communications  Network  (distributed  processing) 
environments.  Further  modeling  and  analysis  of  the  entity  content  of  these  reports  is  necessary  to 
establish  the  logical  databases  and  their  structure  needed  to  provide  efficient  database  administration  to 
support  the  (TM  function.  These  reports  are  seen  as  integral  to  the  successful  implementation  of  a 
DoD-wide  Capacity  Management  Function.  Whether  these  reports  are  produced  on  a  daily,  weekly,  or 
monthly  frequency  is  up  to  organizational  management. 

However,  these  (and  other  reports  desired)  must  be  (1)  standard  in  content  and  presentation  format,  (2) 
be  produced  from  similar  sources  and  databases  (as  appropriate),  (3)  be  constructed  to  permit  summary 
reports  to  be  prepared  for  executive-level  reporting,  and  (4)  illustrate  the  issues  that  the  Capacity 
Management  Function  needs  to  monitor. 

As  an  aid  to  better  understand  the  general  type  of  reporting  information  that  is  contained  in  these 
reports,  the  following  describes  some  typical  categories  of  data  collection: 

•  For  example,  performance  measurement  data  should  be  collected  on  (1)  performance 
bottlenecks;  (2)  service  to  users  (in  terms  of  system  availability);  (3)  exception  reports  (for 
defined  thresholds  exceeded);  and  (4)  workload  characteristics  (number  of  packets  or 
transactions  processed,  I/O's  used),  etc. 

•  Examples  of  capacity  plarming  repwrt  data  needed  concerns  (1)  systems  capacity  and  reserve 
capacity  used;  (2)  workload  trends  (in  terms  of  transaction  rates  by  user)  and  volumes;  (3) 
workload  processing  (in  terms  of  resource  usage);  (4)  performance  predictions  (in  terms  of 
establishing  acceptable  limits,  saturation  levels  of  system  components,  etc.). 
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Capacity  Management  Source  Functional  Area  Afiected 

Reporting  Activity 

Requirements  _ _ 


4-62 


Table  4-5  Capacity  Management  Reporting  Requirements  Table 


Section  5 

Recommendations 


Introduction 

The  workshop  team  envisions  a  new  strategic  direction  for  the  DoD  Capacity  Management  Function, 
and  the  re-engineering  of  component  processes,  that  will  impact  all  DoD  Agencies  and  Services 
performing  DU/IS  activities.  This  visionary  approach  to  Capacity  Management  was  developed 
through  the  appUcation  of  the  DoD  CIM  Functional  Process  In^)rovement  Initiative.  The  result  of  this 
effort  will  enable  establishment  of  a  Capacity  Management  Function  that  is  critical  and  central  to  the 
accomplishment  of  DoD  Information  Management  objectives. 

The  improvement  opportunities  presented  herein  are  the  result  of  extensive  analysis  conducted  during 
the  development  of  the  activity  and  data  models.  The  workshop  team  beheves  that  these  in^)rovement 
opportunities  are  essential  to  the  effective  and  successful  implementation,  and  management  of  the 
Capacity  Management  Function  across  the  DoD. 

In  addition  to  the  primary  recommendation  for  DoD  to  adopt  the  TO-BE  Capacity  Management 
Function  as  the  standard  process  "ten:q>late"  for  DoD,  the  workshop  team  discovered  14  Improvement 
Opportunities  which  are  listed  as  follows: 

1.  Provide  Dll-Wide  Management  of  the  Capacity  Management  (CM)  Function. 

2.  Provide  an  Effective  Organizational  Structure  for  Managing  the  CM  Function. 

3.  Include  CM  in  IRM  Business  Planning. 

4.  Acquire  Standard  Performance  Software  Tools  from  Vendors  for  DUAS  Components. 

5.  Provide  Central  Focal  Point  for  CM  Services. 

6.  Provide  Better  CM  Coordination  with  CDAs,  Users,  and  IPCs. 

7.  Collect,  Organize,  and  Evaluate  CM  Costs. 

8.  Provide  Adequate  Funding,  Training,  and  Staffing  for  CM. 

9.  Ensure  Standard  Reporting  of  CM  Support  Requirements. 

10.  Establish  a  Configuration  Control  Board. 

11.  Provide  for  Standard  CM  Documentation,  Reporting,  and  Modeling  Requirements. 

12.  Provide  for  Dll-Wide  Response-Time  Measurements. 

13.  Provide  for  Dll-Wide  Performance  Simulation  and  Capacity  Predictions. 

14.  Provide  for  Dll-Wide  Network  Component  Measurement  Capability. 
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The  Improvement  Opportunities  identified  by  the  Workshop  Team,  are  described  below.  Explicit 
references  to  Activity  Models  are  inSection  4.  and  issues  affecting  CM  policy  in[4)lementation  are  in 
Section  2. 


Improvement  ODPortunities 

Improvement  Opportunity  #1:  Provide  Dll-Wide  Management  of  the  Capacity 
Management(CI^  Function 

Mapping  to  Activity  Model:  AO 

References  to  Section  2:  “Issues  Affectine  CM  Policy  Imolementation": 

(1)  Roles  and  Responsibilities 

(6)  Centralized  Management  Control  and  Distributed  Execution 

(7)  Implementation  Support 

GOAL:  (1)  Establish  a  C^acity  Management  Steering  Group  for  coordination  of  CM  issues 

affecting  the  DII  Information  System  environments  (e.g..  Megacenters,  networks, 
communications,  and  base-level  installations,  etc.). 

(2)  Ensure  centralized  control  and  distributed  execution  of  the  CM  Function 
Throughout  DoD  to  provide  better  management  of  collective  and  'local "  CM  issues 
and  services. 

(2)  Develop  a  centralized  control  and  distributed  execution  management 
implementation  strategy  which  will  create  a  centralized  CM  Function  in  DoD,  and 
leverage  the  currently  existing  CM  Function  capabilities  in  each  Service  and  Agency. 

DEHCIENCY: 


(1)  There  is  currently  no  formal  centralized  function  (e.g.,  CM  Steering  Group)  for 
the  coordination  of  CM  issues  affecting  all  DII/IS  configurations  across  the  DoD. 

(2)  The  CM  programs  which  currently  exist  are  not  implemented  in  a  consistent 
manner  within  the  Services  and  Agencies,  and  are  not  managed  by  a  DoD-wide  central 
organization. 

RECOMMENDATION: 

(1)  Create  a  CM  Steering  Group  at  the  DISA  executive  level.  This  group  will  be 
composed  of  senior  level  managers  representing  Megacenters,  CD  As,  networks, 
communications,  and  base-level  installation  CM  Functions.  Functional  areas,  as  well 
as  user  communities,  will  be  represented.  The  Steering  Group  will  ensure  that  all 
appropriate  organizations  will  have  the  opportunity  to  participate  in  the  CM  process. 

(2)  The  CM  Steering  Group  will  be  responsible  for  overall  direction  of  the  CM 
Group.  Responsibilities  will  include;  setting  and  implementing  policy,  promulgating 
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standards  and  procedures,  estabUshing  reporting  requirements,  identifying  and 
coordinating  security  requirements  that  affect  system  performance,  and  preparing 
DoD  level  strategic  CM  plans.  The  group  will  also  be  responsible  for  evaluation  of 
costs  and  acquisition  issues  that  affect  the  CM  Function. 

(3)  Leverage  current  capabilities  by  giving  execution  authority  to  the  Services  and 
Agencies  for  their  respective  sites  and  workloads.  In  this  way,  current  CM  programs 
(e.g.,  in  DLA  at  DSAC,  in  the  Air  Force  at  Wright  Patterson  AFB,  etc.)  are 
preserved  and  continue  to  deal  with  the  sites  and  workloads  that  they  each  know  best. 

(4)  The  central  group  would  bring  each  program  into  compliance  with  the 
requirements  of  the  central  program.  This  approach  preserves  current  skills  and 
knowledge  and  provides  a  measure  of  reassurance  to  the  Services  and  Agencies  that 
their  CM  concerns  and  issues  are  dealt  with  by  analysts  who  fully  understand  their 
problems. 

Concept  of  Use; 

The  Capacity  Management  (CM)  Steering  Group  is  a  cooperative  function  that 
oversees  the  promulgation  and  enforcement  of  (TM  standards,  methodologies,  and 
procedures.  These  include:  procedures,  data  collection,  storage  management,  capacity 
planning  and  performance  monitoring/mning  areas  of  DU  Information  Systems 
environment  (IPCs,  Megacenters,  CDAs,  etc).  The  CM  Steering  Group  also  sets 
standards,  defines  DoD  level  reporting  requirements,  coordinates  preparation  of 
management  level  strategic  capacity  plans,  etr.  It  provides  centralized  control  and 
distributed  execution  of  the  CM  Function  through  DoD-wide  CM  coordination  of 
Capacity  Management  activities  for  the  DII. 

Within  this  concept  of  use,  the  CM  Steering  Group  function  would  reside  at  the  DISA 
Executive  level.  It  would  be  composed  of  senior  managers  who  represent  DISA, 
DISO,  DISN,  each  Megacenter,  CDAs,  and  base-level  military  installations.  The 
Steering  Group  would  meet  on  a  periodic  (e.g.,  quarterly)  basis  to  resolve  agenda 
items,  and  provide  direction  on  issu^,  to  the  DII  Information  Systems  community 
over  which  it  presides. 
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InfiDrovemeiit  OpDortunitv  #2;  Provide  an  Effective  Organizational  Structure  for  Managing  the 
CM  Function. 

Mapping  to  Activity  Model:  AO 

References  to  Section  2:  ^'Issues  Affecting  CM  Policy  Implementation": 

(5)  Organizational  Structures 

(6)  Centralized  Management  Control  and  Distributed  Execution 

(7)  Implementation  Support 

GOAL:  (1)  Define  CM  as  a  major  function  of  the  DO,  and  place  this  function  at  an 

appropriate  level  (e.g.,  division)  within  DoD  IS  organizations  to  ensure  effective 
implementation  of  the  CM  Function. 

(2)  Staff  the  CM  Function  at  all  IPCs  at  a  level  adequate  to  perform  the  CM  Function 
on  a  par  with  other  major  functional  areas  of  the  IPC. 

DEnCIENCY: 

(1)  Currently,  the  CM  Function  is  not  always  implemented  at  an  organizational  level 
that  will  ensure  effective  implementation. 

(2)  The  CM  Function  often  does  not  have  adequate  numbers  of  personnel,  nor 

personnel  with  correct  skills,  to  ensure  effective  implementation  of  the 
CM  Function. 


RECOMMENDATION; 

(1)  Identify  elements  of  DoD  organizational  structures  that  perform  CM  activities, 
and  ensure  that  they  are  structured  to  permit  standard  integration  of  the  CM  Function 
DoD-wide.  Further,  this  will  foster  effective  management  of  individual  organizational 
CM  practices  in  a  unified  manner. 

(2)  The  CM  Function  at  all  IPCs  should  be  adequately  staffed  by  full-time 
practitioners  at  an  organizational  level  on  a  par  with  the  other  major  functional  areas 
of  the  IPC. 

(3)  Elevate  the  CM  Function  to  an  organizational  level  in  the  IPC  that  will  ensure 
credible  information  is  provided  to  decision  makers  that  is  more  responsive  to  their 
needs. 
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Improvement  OpDortunitv  #3;  Include  CM  in  IRM  Business  Planning 


Mapping  to  Activity  Model:  AO 

References  to  Section  2:  "Issues  Affecting  CM  Policy  Implementation": 

(9)  Life-Cycle  Design  and  Development 

GOAL:  (1)  To  Integrate  CM  in  the  Agency  and  Departmental  IRM  planning  process. 

(2)  Establish  a  process  to  allow  CM  to  participate  in  the  development  of  long-range 
IRM  business  plans. 

DEnCIENCY: 

(1)  Currently,  CM  management  is  often  unaware  of  larger  IPC,  Agency,  or  DoD  IS 
business  plaiming  issues.  By  not  having  a  complete  understanding  of  IRM  business 
requirements,  the  CM  Function  is  not  as  effective  as  it  should  be. 

(2)  The  CM  Function  is  not  typically  integrated  into  the  IRM  planning  process. 
RECOMMENDATION: 

(1)  Involve  CM  management  more  directly  in  the  enterprise  business  planning  process 
including  short  and  long-range  planning,  acquisitions,  budget  development,cos: 
analyses,  etc. 

(2)  Provide  a  process  by  which  CM  is  involved  in  all  elements  of  the  IRM  Business 
Plaiming  Process  which  may  a.ffea  the  performance  or  planning  of  information 
Systems. 
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ImDrovemcnt  ODPOrtunitv  #4;  Acquire  Standard  Performance  Software  Tools  From  Vendors  for 
DIl/IS  Components 

Mapping  to  Activity  Model:  A3112,  A42 

References  to  Section  2:  "Issues  Affectine  CM  Policy  Implementation": 

(2)  Standards 

(3)  Reporting 

(8)  Baseline  DII/IS  Models 

GOAL:  To  provide  performance  measurement  capabilities  and  system  utilization  tools  for  all 

components  that  comprise  the  DC  architecture. 

DEnCIENCY: 

(1)  Performance  measurement  software  is  often  not  available  for  all  components  of 
the  DII/IS  environment. 

(2)  Integrated  network  performance  measurement  tools  are  needed  across  DoD 
heterogenous  network  environments. 

(3)  There  is  no  continuous  performance  measurement  data  collection  process  across 
networks.  There  is  no  data  collection  activity  analogous  to  mainframe  data  collection 
processes  (e.g.,  RMF  and  SMF  data  collection  routines  on  an  IBM  mainframe),  in 
which  performance  and  usage  data  is  continuously  collected  and  saved  in  database  files 
for  later  use.  This  basic  data  collection  is  required  to  support  routine  performance  and 
utilization  reporting,  trend  analysis  and  other  normal  capacity  management  activities. 

(4)  Current  network  measurement  tools  are  vendor,  platform,  and  architecture 
specific,  and  do  not  enable  interoperable  performance  measurements. 

The  following  presents  some  examples  of  current  vendor,  platform,  and  architecture 
specific  tools  and  the  components  they  measure: 

•  For  SNA  -  Netview  Performance  Monitor  (NPM),  Net/Master  and  NetSpy 

•  For  IP  Router  Networks  -  NetCentral,  NetExpert, 

•  For  Ethernet  LANs  -  Network  General  Sniffer  and  HP  Network  Advisor 

•  For  FDDl  optical  data  networics  •  Spectrum  Netwoik  Management  System 

•  For  T1  Commimication  Backbones  -  AT&T  Comsphere  System 
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Although  the  goal  is  for  the  DII  to  migrate  to  an  "open  systems"  interconnection 
environment,  there  are  no  tools  that  provide  an  interoperable  measurement  capability 
for  these  end-to-end  heterogenous  networks  .  Further,  existing  tools  do  not  provide 
for  aggregation  of  measurement  data  into  a  collective  and  meaningful  view  of  a  system 
being  measured. 

RECOMMENDATION: 

(1)  Request  that  vendors  provide  standard  performance  measurement  software  that  will 
enable  the  analysis  of  performance  and  capacity  utilization  for  interoperable 
components  in  the  DII/IS  (end-to-end)  environment.  This  software  will  permit  more 
accurate  peer-to-peer  and  end-to-end  performance  analysis. 

(2)  Request  that  vendors  develop  and  provide  standard  performance  measurement 
software  to  enable  collection  of  performance  data  across  DII/IS  configurations  (PC-to- 
mainframe)  .  This  software  will  permit  uniform  performance  reporting  for  all  DII/IS 
environments. 

(3)  Develop  a  DoD  standard  performance  specification  for  performance  measurements 
for  vendor  compliance  across  all  DII/IS  components. 
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Improvement  OPDortunitv  #5:  Provide  Central  Focal  Point  For  CM  Services 


Mapping  to  Activity  Model:  All 
References  to  Section  2:  "Issues  Affectine  CM  PoUcv 

(1)  Roles  and  Responsibilities 

GOAL:  Establish  a  more  effective  interface  for  providing  CM  support  services  with  all 

requestors  (IPC,  CDA,  Megacenter,  User  Conununity,  etc.)  for  problem  identification 
and  management  of  CM  issues. 


DEnaENCY: 


(1)  There  is  no  central  point  of  contact  within  the  CM  Function  where  CM  support 
requests,  support  requirements  and  other  tasking  is  serviced. 

(2)  There  is  no  formal  IPC  Help  Desk  interface  to  external  offices  (requestors)  for 
projea  management  activities  associated  with  the  CM  Function,  to  provide  liaison  and 
fee^ack  on  performance  issues. 

(3)  Often  skill  levels  of  IPC  personnel  who  now  perform  "Help  Desk"  functions,  are 
inadequate  to  interpret  problems  or  assign  problems  to  the  correa  IPC  functional  area 
for  action. 

RECOMMENDATION: 

(1)  Establish  a  formal  point  of  contaa  for  the  CM  Function  to  review,  analyze,  and 
assign  requests  for  support  in  order  to  effectively  satisfy  to  receive  support 
requirements,  and  requests  in  the  most  cost  effective  manner. 

(2)  Provide  adequate  training  for  Help  Desk  personnel  concerning  CM  functional 
activities,  to  enable  them  to  more  effectively  screen  requests  for  CM  Services. 

(3)  Ensure  that  the  "Help  Desk"  for  the  CM  Function  becomes  the  "front  door" 
where  liaison  and  feedback  on  support  are  provided  to  external  organizational 
elements. 

(Note:  This  recommendation  has  been  incorporated  into  the  A1  Manage  Service  model.  However, 
the  issues  discussed  here  still  require  resolution.) 
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ImDrovemeiit  Opportunitv  #6;  Provide  Better  CM  Coordination  With  CDAs,  Users,  And  IPCs. 

Mapping  to  Activity  Model:  A1 1 
References  to  Section  2:  "Issues  Affecting  CM  Policy 

(1)  Roles  and  Responsibilities 
(S)  Organizational  Structures 

GOAL:  (1)  Ensure  that  Functional  Descriptions  (FDs)  contain  well-defined,  meaningful  aiul 

measurable,  performance  objectives  and  metrics  to  enable  the  CDAs  to  write  more 
resource-efficient  s^lication  programs. 

(2)  Establish  a  user  interface  with  the  CDA  Community  to  provide  timely  resource 
requirement  information  on  current  and  new  applications  or  system  (tesigns. 

(3)  Establish  a  process  by  which  the  CM  Function  is  included  as  a  formal  coordinator 
of  all  Service  Level  Agreements  (SLAs)  and  Service  Level  Objectives  (SLOs). 


DEnCIENCY: 


(1)  Often  software/program  application  code  is  not  written  to  make  efficient  use  of 
system  resources,  which  results  in  added  cost  for  system  utilization  to  the  user. 

(2)  Functional  Descriptions  (FD)  have  poorly  defined  performance  objectives  and 
workload  requirements.  This  leads  to  inadequate  achievement  of  Service  Level 
Objectives. 

(3)  Often  CDAs  and/or  Functional  Activity  Proponents  do  not  provide  timely 
resource  requirements  to  the  CM  Function.  Thra,  time  and  resources  cannot  be  made 
available  without  "crash"  efforts. 

(4)  Frequently  SLAs/SLOs  are  not  developed  or  coordinated  with  the  CM  Function. 
This  results  in  requirements  to  meet  performance  objectives  that  may  not  always  be 
obtainable.  Furthn,  the  feasibility  of  acconq)lishing  SLOs  is  not  always  known. 

RECOMMENDATION: 

(1)  Review  system  performance  utilization  of  applications  to  determine  more  efficient 
methods  of  executing  user  programs  that  can  result  in  reduced  cost  to  the  user. 

(2)  Establish  a  Software  Performance  Engineering  program  to  ensure  that  resource 
estimates  are  provided  for  as  major  milestones  in  the  application  or  system  design 
development  life-cycle. 

(3)  Ensure  that  customers  and  CDAs  provide  FDs  that  contain  well-defined 
performance  objectives  and  workload  estimates.  The  CM  staff  should  be  a  part  of  the 
performance  objective  development  process. 
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(4)  Ensure  that  no  new  application,  or  major  change  to  an  existing  application  is 
installed  without  first  providing  the  performance  staff,  CD  A,  etc.,  with  resource 
estimates  and/or  benchmarks.  (With  the  new  prototyping  development  methodology 
available,  this  information  should  be  more  readily  available.) 

(5)  Ensure  a  process  is  in  place  to  allow  the  CM  Function  to  review,  coordinate,  and 
determine  feasibility  of  achieving  the  SLAs/SLOs  during  the  development  process. 
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Improvement  Opportunitv  #7:  Collect,  Organize,  and  Evaluate  CM  Costs 


Mapping  to  Activity  Model:  A13,  A2 

References  to  Section  2:  "Issues  Affecting  CM  Policv  Imolenuntation": 

(4)  Cost  Accounting 

GOAL:  (1)  Evaluate  the  costs  associated  with  the  CM  Function  to  promote  quality  processes 

dtat  result  in  cost  savings,  and  document  the  cost  of  doing  business. 

(2)  Establish  a  CM  cost  recovery  system  (i.e.,  Fee-For-Service)  to  permit  collection 
of  performance  and  memory  utilization,  and  other  cost  data. 

DEFICIENCY; 

(1)  There  is  no  consistent  collection  and  reporting  of  performance  and  other  direct 
cost  data  that  will  demonstrate  the  cost  and  quality  of  CM  hmctional  activities. 

(2)  There  is  no  effective  or  standard  process  for  the  collection  of  resource  utilization 
data  that  will  permit  cost  evaluation  and  reporting. 

RECOMMENDATION: 

(1)  Ensure  a  process  is  in  place  to  generate  cost  data  on  elements  of  the  CM  Function 
that  will  provide  a  ”big  picture"  of  the  cost  of  doing  business.  These  data  can  be  used 
to  derive  levels  of  efficiency,  and  provide  input  to  evaluations  of  the  quality  of  CM 
activities. 

(2)  Establish  a  database  that  will  provide  data  on  capacity  utilization,  etc.,  and  that 
will  be  useful  in  measuring  us^e  of  system  resources.  This  will  provide  input  in 
determining  the  cost  of  C2q}acity  (e.g.,  memory,  used  disk  space,  I/Os,  security 
overhead,  etc.)  in  relation  to  p^ormance  and  use,  or  loss  of,  available  ciq)acity. 

(3)  Develop  and  implement  a  cost  recovery  system  (i.e.,  Fee-For-Service)  that  will 
permit  accumulation  of  resource  utilization  and  other  cost  data  (e.g.,  c^)acity 
utiUzation,  I/Os,  security  overhead,  CPU  busy,  and  direct  labor  hour  reporting,  etc.). 
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Imoroveinent  Opportunity  #<:  Provide  Adequate  Funding,  Training,  and  Staffing  for  CM 


Mapping  to  Activity  Model:  Al? 

References  to  Section  2:  "Issues  Affecting  CM  Policy  Implementation'': 

(10)  Staffing  Requirements 

(11)  Training 

GOAL:  (1)  Ensure  that  sufficient  levels  of  staffing,  skills  training,  and  funding  are  provided 

to  ensure  effective  execution  of  the  CM  Function  at  operational  levels. 

(2)  Identify  and  define  formal  job  descriptions  and  skill  sets  required  to  perform  the 
CM  Function  for  all  coaqx)nents  of  the  DII/IS.  This  includes  job  descriptions  for 
positions  in  network,  communication  and  PC-client/server  areas,  etc. 

DEnaENCY: 


(1)  There  are  insufficient  levels  of  skills,  staffing,  training,  and  funding  made 
available  to  support  CM  Functions. 

(2)  There  are  no  standard  or  consistent  position  descriptions  for  CM  Functions  within 
or  between  the  Services  and  Agencies  of  the  DoD. 

RECOMMENDATION: 

(1)  Provide  adequate  training  and  funding  for  development  of  personnel  skills  needed 
to  perform  the  CM  Function. 

(2)  Ensure  adequate  CM  personnel  staffing  levels  exist  at  all  IPC,  CDA,  and  base- 
level  installations. 

(3)  Identify  skill  sets  and  requirements  for  all  positions  that  are  necessary  to  manage 
and  perform  activities  associated  with  capacity  management,  performance 
measurements,  ciq)acity  planning,  modeling,  etc. 

(4)  Develop  formal,  standard,  and  consistent  job  descriptions,  that  are  i^roved  by 
uf^r-management  for  the  performance  of  CM  Functions  across  the  DII/IS. 
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Improvement  Opportunity  #9;  Ensure  Standard  Reporting  of  CM  Support  Requirements 


Mapping  to  ActivUy  Model:  A13 

References  to  Section  2:  "Issues  Affectine  CM  Policy  Implementation": 

(3)  Reporting 

(4)  Cost  Accounting 

GOAL:  Establish  a  process  for  collecting  needed  CM  support  requirements  (e.g.,  financial, 

staffing,  training,  contracts,  etc.)>  and  developing  an  overall  process  to  support 
standard  reporting. 


DEnCIENCY: 


(1)  Often  there  does  not  exist  a  standard  process  for  collection  and  reporting  of 
support  requirements  that  are  needed  for  effective  and  fiscally  sound  management  of 
the  CM  Function. 

(2)  CM  Function  support  reporting  requirements  are  inconsistent  or  are  not 
standardized  across  the  DoD. 

(3)  The  CM  Function  support  requirements  are  not  currently  identified  or  budgeted  to 
provide  for  a  successful  inq)lementation  and  continuation  of  this  CM  Function. 

RECOMMENDATIONS: 

(1)  Establish  a  formal  standard  process  for  collection  and  reporting  of  CM  Functional 
support  requirements  that  includes  financial,  pnsonnel,  training  and  contractual 
support,  etc. 

(2)  Identify  short-  and  long-range  requirements  that  must  be  funded  to  support  the 
ongoing  CM  Function.  This  should  occur  on  a  periodic  (e.g.,  quarterly)  basis. 

(3)  Establish  the  personnel,  training,  contract  support  and  funding  requirements 
necessary  to  implement  the  CM  function  in  the  new  Megacenter  environment,  as  well 
as,  at  CDAs,  ITCs,  base-level  military  installations,  etc. 
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Establish  a  Configuration  Control  Board 


Mapping  to  Activity  Model:  AO 

References  to  Section  2:  Issues  Affecting  CM  Policy  Imolementation": 

(1)  Roles  and  Responsibilities 

(5)  Organizational  Structures 

(6)  Centralized  Management  Control  and  Distributed  Execution 

GOAL:  Establish  a  Configuration  Control  Board  (CCB)  structure  to  issue  policy  and  guidance 

for  managing  changes  to  the  DII  architectural  configuration. 


DEnClENCY: 


(1)  There  is  no  centralized  control  for  managing  configuration  changes  to  the  DU. 

(2)  There  is  no  formal  s^iproach,  process,  or  standards  for  managing  and 
implementing  IS  configuration  changes  across  the  DU. 

RECOMMENDATION: 


(1)  Establish  a  Configuration  Control  Board  to  provide  policy,  guidance,  and 
oversight  of  changes  to  the  DII. 

(2)  The  CCB  should  develop  and  issue  configuration  management  policy  and  overall 
standards  and  review  processes  to  provide  structure  for  managing  changes  to  Dll 
architecture. 

(3)  The  CCB  should  also  provide  the  direction  and  guidance  for  implementing  DU 
configuration  and  change  management  procedures. 

(4)  This  board  should  be  composed  of  senior  managers  who  represent  all  affected 
Services  and  Agencies  of  the  DoD,  and  including  C3I. 
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Improvement  OpDortunitv  #11:  Provide  for  Standard  CM  Documentation,  Reporting,  and 
Modeling  Requirements 

Mapping  to  Activity  Model:  A2,  A3,  A4,  AS 

References  to  Section  2:  "Issues  Affecdnt  CM  Policy  Implementation": 

(2)  Standards 

(3)  Reporting 

(8)  Baseline  on/IS  Models 

GOAL:  Establish  standard  documentation  procedures,  reporting  requirements,  and  modeling 

procedures  for  DoD-wide  CM  activities. 

DEnClENCY: 

(1)  There  are  no  standard  and  consistent  DoD-wide  documentation  and  rqxjrting 
procedures  for  the  CM  Function. 

(2)  There  is  no  standard  sq)proach  for  documenting  and  reporting  activities  of  the  CM 
Function  for  all  elements  of  the  DII/IS. 

(3)  There  is  no  capability  to  capture  the  "big  picture”  of  all  collective  CM  Function 
activities  across  the  DII/IS. 

(4)  There  are  no  standard  modeling  practices,  requirements,  or  procedures  for  CM 
activities  DoD-wide. 


RECOMMENDATION: 

(1)  Establish  standard  requirements  and  frequencies  for  documenting  and  reporting 
CM  functional  activities  (e.g.,  performance  measuremmits,  reserve  capacity,  resource 
utilization,  etc.),  DoD-wide. 

(2)  Reports  should  enable  the  preparation  of  a  "big  picture"  (e.g.,  available  and 
reserve  capacity,  resource  utilization,  workload  growth  forecasts,  staffing 
requirements,  cost  data,  etc.)  of  the  CM  Function  across  the  DoD. 

(3)  Establish  standard  modeling  information  requirements  and  procedures  so  that  data 
can  be  collected  and  merged  in  order  to  model  composite  DII/IS  environments,  and 
prepare  comparative  reports. 

(Note:  A  table  of  recommended  rq)orts  for  CM  is  presented  in  Table  4-5  page  4-62.  Further  a 
standard  approach  to  modeling  has  been  incorporated  into  the  A5  Activity  model.) 
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Improvement  Opportunitv  #12;  Provide  for  DIl>Wide  Response>Time  Measurements 
Mapping  to  Activity  Model:  A3 

References  to  Section  2:  "Issues  Affecting  CM  Policy  Implementation": 

(2)  Standards 

(8)  Baseline  DII/IS  Models 

GOAL:  Develop  the  capability  to  measure  response-times  for  all  components  of  the  DU  from 

PC-to-Mainffame  (end-to-end)  including  mainframe/host  computers,  networks,  and 
communications  environments. 

DEnCIENCY: 

Currently,  the  differences  in  the  performance  measures  and  non-standard  performance 
specifications  from  vendors  of  DII/IS  con^nents  (e.g.,  in  Mainframes,  Networks, 
and  Communications)  preclude  the  accurate  measurement  of  end-to-end  response  time. 
This  is  due  to  the  lack  of  interoper^ility  of  many  DQ/IS  components,  which  limits 
measurement  capabilities  for  system  response-time  in  DoD  heterogeneous 
environments. 

RECOMMENDATION: 

(1)  Define  requirements,  and  obtain  software  for  performance  measurement 
c^bilities  that  apply  to  DII/IS  components  (from  vendors  or  government  sources) 
which  will  permit  interoperable  response-time  measurement  and  data-collection 
capabilities  for  all  DII  components.  PC-to-Mainffame  (end-to-end),  regardless  of 
protocols  used. 

(2)  Enable  measurement  of  response-times  for  any  combination  of  DII  components 
world-wide.  Combinations  may  include:  (1)  mainffame-to-mainffame,  (2) 
mainffame-to-network,  (3)  network-to-client/server,  and  (4)  communications  modes 
and  media  (e.g.,  Front-End-Processors,  T1/T3  lines,  FDDI  backbones,  SONET, 
ATM,  satellites,  mobile,  ^.). 

(3)  Provide  performance  measurement  software  that  will  permit  monitoring  and 
measurement  of  all  types  of  networks.  One  element  of  the  required  software  is  the 
Simple  Network  Management  and  Protocol  (SNMP)  for  TCP/D*  operations  that  must 
be  present  in  all  applicable  network  components. 

An  example  of  the  performance  measurements  that  are  needed  for  admiring  PC-to- 
Mainffame  (end-tCHend)  response-time,  are  shown  in  Figure  2-2  Peer-to-Peer 
Propagation  Delay  Response-Time  Measurements.  Since  PC-to-Mainffame 
measurements  are  difficult  (if  not  impossible)  in  current  DII/IS  configurations,  this 
figure  provides  an  exaixy)le  of  how  we  might  measure  total  PC-to-Mainframe 
response-time  using  a  peer-to-peer  measurement  construa. 
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Improvement  Opportunity  #13:  Provide  for  DII>Wide  Performance  Simulation  and  Capacity 
Predictions 

Mapping  to  Activity  Model:  A4,  A5 

References  to  Section  2:  "Issues  AffecHne  CM  Policy  Imolementation": 

(8)  Baseline  DII/IS  Models 

(9)  Life-Cycle  Design  and  Development 

GOAL:  To  establish  a  "what-iC  simulation  capability  for  modeling  perfonnance,  and 

developing  capacity  predictions,  for  new  or  proposed  changes  to  a  DII/IS 
configuration. 


DEFICIENCY: 


Currently  few  capabilities  exist  to  model  and  predict  the  performance  of  alternative 
configurations  for  the  DII/IS  Capacity  Management  Function.  The  Plan  Capacity 
(A4)  and  Maintain  Capacity  Management  Models  (A5)  activities  of  CM  are  not 
typically  used  in  the  communications/network  environment.  Performance  predictions 
and  their  relationship  with  SLOs  are  mostly  confined  to  the  mainframe  environment. 

If  we  are  to  perform  effective  and  efficient  capacity  planning  for 
communications/network  environments,  we  will  have  to  provide  modeling  capabilities 
for  all  Dn/IS  environments. 

RECOMMENDATION: 

(1)  Establish  the  capability  to  realistically  and  accurately  simulate  "what  if  " 
modifications  to  any  element  of  the  DII/IS  configuration.  This  will  allow  performance 
prediction  of  selected  configurations  for  edacity  planning,  including  evaluation  of 
potential  configurations  and  user  workload/application  scenarios,  and  adding  new 
networks. 

(2)  Establish  the  capability  to  be  comprehensive  enough  to  include  all  modeling 
capabilities  needed  for  PC-to-  mainframe  environments,  including  communication 
systems  and  network  topologies. 

(3)  Require  vendors  to  provide  modeling/simulation  "what  is”  software  that  can  be 
used  for  producing  and  presenting  performance  and  capacity  predictions  of  new  or 
proposed  changes  to  any  Dll/configuration. 
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Improvement  OpDortunitv  #14:  Provide  for  Dll-Wide  Network  Component  Measurement 
Capability 

Mapping  to  Activity  Model:  A3 

References  to  Section  2:  "Issues  Affecting  CM  Policy  Implementation": 

(2)  Standards 

(9)  Life-Cycle  Design  and  Development 

GOAL:  Ensure  that  DO  network  and  communications  conqx)nents  have  standard, 

interoperable,  and  protocol-independent  measurement  capabilities. 

DEnOENCY: 


(1)  Currently  network  con^wnents  are  often  protocol -dependent  and  not  interoperable. 
This  is  caused  by  proprietary  protocols  and  other  vendor-specific  software  that  do  not 
adhere  to  common  performance  measurement  standards.  Often  these  conqranents  can 
not  be  made  interoperable.  When  they  can  be,  this  often  requires  additional  costs  and 
time  to  be  expended  in  obtaining  vendor  modifications  and/or  additions  to  their 
products,  procurement  of  third  party  interface  software,  and  additional  testing  and 
adjustments  to  baseline  network  environments  to  accommodate  these  components. 

(2)  As  Megacenters  and  Dn  configurations  evolve,  and  legacy  systems  are  replaced, 
there  are  no  formal  standards,  or  centralized  control  in  the  DoD  to  ensure  that  all 
hardware  and  software  architectures,  system  components,  and  protocols  are 
interoperable  and  measurable  and  will  enable  capacity  and  performance  measurements 
to  be  performed.  Further,  and  to  make  measurements  more  difficult,  much  of  the 
difficulty  in  measuring  network  performance  is  due  to  the  heterogenous  non- 
interoperable  nature  of  legacy  systems  and  architectures. 


RECOMMENDATION: 

(1)  Establish  and  enforce  standards,  and  require  vendor  certification  for  the 
measurement  of  network  components  that  are  to  be  configured  into  communication 
systems  and  networks.  Specifically,  newly  proposed  conqwnents  should  be  required 
to  meet  interoperable  performance  measurement  standards,  hardware  and  software 
protocols  and  interface  standards. 

(2)  All  new  start  initiatives  for  the  DII/IS  should  be  based  on  ^ropriate  standards 
and  architectures  that  support  and  provide  for  end-to-end  (e.g.,  "open  systems”) 
performance  measurement  c^abilities. 


(3)  The  DoD  should  initiate  a  partnership  with  industry,  through  conferences  and 
other  available  meetings,  to  describe  and  solicit  vendor  c^abilities  that  will  meet  the 
requirements  stated  herein. 


Appendix  A 
IDEF  Reader’s  Guide 


This  ^jpendix  contains  excerpts  from  the  "ModeUng  for  Managers"'  course  material  provided  by  D. 
Appleton  Company,  Inc. 

A.l  IDEFO  Activity  Models 

The  aim  of  the  IDEFO  activity  modeling  technique  is  to  su^rt  the  specification  of  positive  changes  in 
business  processes  as  well  as  the  discovery  and  documentation  of  data  requirements  from  the  process 
perspective. 

The  activity  modeling  technique,  known  as  IDEFO,  resulted  from  the  Air  Force's  Integrated  Computer 
Aided  Manufacturing  (ICAM)  program  and  is  recognized  by  the  Air  Force  as  an  important  technique  for 
modeling  activities.  The  technique  has  been  adopted  b^use  of  its  flexibility  and  widespread  use 
throughout  business,  industry,  and  government. 

A  completed  activity  model  graphically  depicts  the  specific  steps,  operations,  and  information  needed  to 
perform  an  activity.  Models  also  show  how  specific  activities  are  related  to  one  another. 

A. 1.1  Activities 

An  activity  is  a  named  process,  function,  or  task  that  occurs  over  time  and  has  recognizable  results. 
Although  activities  are  performed  within  functional  areas  of  an  organization,  it  is  important  that  they  are 
defined  independent  of  any  functional  area.  The  tendency  to  model  the  organization  strucmre  rather  than 
its  processes  should  be  avoided.  In  a  diagram,  the  activity  is  represented  by  a  rectangular  box  with  the 
verb  phrase  that  describes  the  activity.  Examples  of  activities  are  depicted  in  Figure  A*1 . 


Enter 

Approve 

Ship 

Customer 

Order 

Order 

Order 

Figure  A-1.  Activity  Examples 


‘  D.  Appleton  Company,  Inc.  Business  Modeling  for  Managers.  Manhattan  Beach,  CA,  1990. 
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A.1.2  ICOMs 


The  term  ICOM  refers  collectively  to  the  group  of  information  flows  between  activities  which  have  one 
of  four  roles  in  the  activity; 


Control 


Input 


Activity 

Name 


AO 


Output 


\ 


AaMtjf  Number 


Machaniam 


Figure  A-2.  ICOM  Placement 


Input  -  Information  or  material  used  to 
produce  the  output  of  an  activity  ; 

Control  -  Information  or  material  that 
constrains  or  controls  an  activity; 

Output  -  Information  or  material  produced 
by  or  resulting  from  the  activity;  and, 

Mechanism  -  Usually  people,  machines,  or 
systems  that  perform  the  activity. 


The  particular  role  of  an  ICOM  is  identified  by  the  position  of  its  arrow  in  relation  to  the  activity  box. 
The  placement  of  ICOMs  in  relation  to  an  activity  is  illustrated  in  Figure  A-2. 

A. 1.3  Context  Diagrams 


A  context  diagram  is  a  single  diagram 
which  illustrates  the  highest  level 
activity  and  its  information  or 
materials.  The  context  diagram  shows 
an  activity  being  explored  with  its 
associated  ICOMs.  Since  the 
technique  is  hierarchical,  this  activity 
represents  the  entire  subject  being 
modeled.  The  "viewpoint”  and 
purpose  of  the  model  are  typically 
stated  on  the  bottom  right  tumd  side 
of  the  diagram.  Figure  A-3  depicts 
an  example  of  a  context  diagram, 
using  the  activity  "Process  Order". 

The  activity  depicted  in  the  context 
diagram  is  typically  numbered  AO. 

Figure  A-3.  Context  Diagram 
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A. 1.4  Node  Trees 


A  node  tree  shows  the  activities,  without  their  ICOMs,  on  a  single  hierarchical  diagram  for  easy 
reference.  Each  node,  or  dot,  on  the  tree  represents  an  activity.  Each  arc,  or  line,  from  one  activity  to 
the  next  lower  level  activity  represents 
a  decomposition  relation^p.  The 
structure  shows  the  activities  and 
subactivities  within  the  model. 

Figure  A-4  depicts  a  node  tree  for  the 
major  activity  Process  Order.  This 
activity  was  decon^sed  into  three 
major  subactivities.  Activity  A2, 

Approve  Order,  has  been  further 
d«;omposed  into  four  subactivities. 


A.  1.5  Decomposition  Diagrams 


Figure  A-4.  Node  Tree  Example 


Each  activity  on  the  diagram  may  be  depicted  in  more  detail, 
or  decon^xjsed,  on  a  separate,  lower  level  diagram  referred  to 
as  a  decomposition  diagram.  Unlike  a  node  tree,  the 
decomposition  diagram  depicts  only  one  level  of  activities 
within  the  hierarchy.  A  d^mposition  diagram  contains  all 
the  child  sunivities  of  the  parent  activity.  The  decomposition 
diagram  allows  a  complex  activity  to  be  broken  down  into 
smaller,  simpler,  more  detailed  activities.  As  a  general  rule, 
each  decomposition  diagram  should  contain  at  least  three  and 
no  more  than  six  activities. 

Figure  A-S.  Decomposition  Diagram 


A. 1.6  ICOM  Glossary 

In  addition  to  the  diagrams,  a  complete  ICOM  glossary  is  necessary  to  fully  convey  a  common 
understanding  of  the  model.  Each  ICOM  should  be  defined  in  terms  of  its  use  and  intent  with  respect  to 
the  model.  ICOM  definitions  should  be  independent  of  the  ICOM  role  in  relation  to  an  activity,  as  an 
ICOM  may  have  a  different  role  on  different  activities. 


A.  1.7  Activity  Descriptions 


To  aid  in  communicating  the  activity  model  to  people  unfamiliar  with  the  IDEFO  technique,  we  typically 
provide  a  detailed  activity  description  of  each  activity  box  represented  by  the  model.  These  descriptions 
detail  the  ICOMs  of  the  activity  as  well  as  other  activities  affected  by  the  ouq)uts.  The  activity 
description  should  be  able  to  stand  alone  as  a  means  for  communicating  the  same  information  as  the 
model. 

A.  1.8  Activity  Model  Uses 

There  are  several  uses  of  activity  models  such  as: 

•  AS-IS  Models  -  The  AS-IS  model  communicates  a  consensus  view  of  the  current 
processes  and  ICOMs  and  is  often  used  as  a  discussion  tool  to  identify 
improvement  opportunities  and  to  assess  changes  from  the  implementation  of  new 
processes; 

•  TO-BE  Models  -  The  TO-BE  models  represent  the  desired  activities  and  associated 
ICOMs  based  on  the  implementation  of  improvement  projects  against  the  AS-IS  Baseline; 

•  Data  Discovery  -  Data  elements  of  interest  to  the  enterprise  may  be  extracted  from  an 
examination  of  the  ICOMs  of  an  activity  model.  These  data  elements  can  then  be  used 
when  specifying  transactions  that  are  eventually  used  to  automate  the  process; 

•  Activity  Based  Costing  Framework  -  Activity  models  provide  a  basis  for  analyzing  costs 
in  ABC  analysis.  The  decomposition  of  activities  to  a  very  low  level  allows  the 
application  of  specific  costs  to  activities.  We  can  then  aggregate  these  costs  to  analyze 
the  activities  according  to  the  actual  impaa  they  have  on  the  enterprise's  costs;  and, 

•  Benchmarking  Tool  •  Benchmarking  is  an  activity-based  analysis  tool  for  examining 
"world-class”  processes  in  order  to  replicate  some  of  the  elements  in  similar  processes. 
By  describing  the  activities  in  common  terms,  it  becomes  simple  to  discuss  the 
opportunities  for  improvement  based  on  the  benchmark  model. 
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A.2  IDEFIX  Data  Models 


This  section  provides  a  context  for  reading  and  understanding  IDEFIX  semantic  data  models.  It  is  not 
intended  to  be  an  instruction  manual  in  the  techniques  of  building  such  models.  Rather,  it  is  intended  to 
specify  the  basic  components  of  a  semantic  data  model  and  their  interpretation. 

IDEFIX  has  proven  to  be  a  useful  and  powerful  tool  for  modeling  a  conceptual  schema.  IDEFIX  models 
define  data  in  a  fully  normalized  structure,  which  allows  an  initial  model  to  be  extended  without  altering 
the  initial  set  of  entities,  relationships,  and  attributes.  IDEFIX  models  are  also  being  used  to 
automatically  generate  database  designs  and  data  integrity  control  logic.  IDEFIX  provides  a  full  set  of 
semantic  modeling  capabilities  while  maintaining  the  ’economy  of  concepts”  associated  with  basic 
Entity-Relationship  modeling. 

A.2.1  Components 

The  IDEFIX  modeling  techniques  include  a  set  of  modeling  semantics,  graphic  syntax  for  representing 
the  semantics,  rules  for  modeling,  modeling  procedures,  and  documentation  formats.  An  IDEFIX  model 
can  be  described  as  a  set  of  graphic  diagrams  representing  real  or  abstract  objects,  their  characteristics 
or  attributes,  and  their  relationship  to  one  another.  Data  model  diagrams  are  refined  into  three  different 
levels  of  detail  : 


•  Entity-Relationship,  the  least  detailed  level; 

•  Key-Based,  the  next  level  of  detail  where  keys  and  other  constructs 
are  added;  and, 

•  Fully  Attributed,  the  most  detailed  data  model  level  that  includes  all 
non-key  data. 

A  glossary  that  defines  the  entities  and  attributes  used  in  the  diagrams  is  created  to  support  each  set  of 
models.  Detailed  wrinen  descriptions  of  the  manner  in  which  data  relates  to  other  data,  called  Business 
Rules,  are  also  developed  from  the  models. 

A. 2.2  Entity  Semantics 

An  "entity”  represents  a  set  of  real  or  abstract  things  (people,  objects,  places,  events,  states,  ideas,  pairs 
of  things,  etc.)  which  have  common  attributes  or  characteristics  and  are  of  interest  to  the  organization. 
An  individual  member  of  the  set  is  referred  to  as  an  "entity  instance." 

In  key-based  and  fully  attributed  models,  a  distinction  is  made  between  two  types  of  entities.  An  entity 
is  "identifier-independent"  or  simply  "independent”  if  each  instance  of  the  entity  can  be  uniquely  identified 
without  determining  its  relationship  to  another  entity.  An  entity  is  "identifier-dependent”  or  simply 
"dependent"  if  the  unique  identification  of  an  instance  of  the  entity  depends  upon  its  relationship  to 
another  entity. 

An  entity  is  represented  as  a  box  as  shown  in  Figure  A-6.  If  the  entity  is  identifier-dependent,  then 
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the  corners  of  the  box  are  rounded.  Each 
entity  is  assigned  a  unique  name  that  is 
placed  above  the  box.  The  entity  name  is  a 
noun  phrase  (a  noun  with  optional  adjectives 
and  prepositions)  that  describes  the  set  of 
things  the  entity  represents,  llie  noun 
phrase  is  singular,  not  plural.  Abbreviations 
and  acronyms  are  permitted  only  where 
necessary;  however,  the  entity  name  must  be 
meaningful  and  consistent  throughout  the 
mode).  A  formal  definition  of  the  entity  and 
a  list  of  synonyms  or  aliases  must  be  defined 
in  the  model  glossary.  Although  an  entity 
may  be  drawn  in  any  number  of  diagrams, 
it  only  ^ipears  once  within  a  given  diagram. 

Figure  A-6.  Entity  Syntax 


A.2.3  Non-Specific  Relationship  Semantics 

In  key-based  and  fiilly  attributed  IDEFIX  models,  all  associations  between  entities  must  be  expressed 
as  specific  binary  relationships.  However,  in  the  initial  development  of  a  model,  it  is  often  helpful  to 
identify  "non-specific  relationship"  between  two  entities.  These  non-specific  relationships  are  refined  in 
later  development  phases  of  the  model.  Entities  introduced  to  resolve  non-specific  relationship  are 
sometimes  called  "intersection"  or  "associative"  entities. 

A  non-specific  relationship, 
also  referred  to  as  a  "many  to 
many  relationship",  is  an 
association  between  two 
entities  in  which  each  instance 
of  the  first  entity  is  associated 
with  zero,  one,  or  many 
instances  of  the  second  entity 
and  each  instance  of  the 
second  entity  is  associated  with 
zero,  one,  or  many  instances 
of  the  first  entity.  For 
example,  if  an  employee  can 
be  assigned  to  many  projects 
and  a  projea  can  have  many 
employees  assigned,  then  the 
connection  between  the  entities 
EMPLOYEE  and  PROJECT 
can  be  expressed  as  a 
non-specific  relationship. 


Figure  A-7.  Non-Specific  Relationship  Syntax 
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A  non-specific  relationship  is  depicted  as  a  line  drawn  between  the  two  associated  entities  with  a  dot  at 
each  end  of  the  fine.  See  Figure  A-7.  A  non-specific  relationship  is  named  in  both  directions.  The 
relationship  names  are  expressed  as  a  verb  ore  verb  phrase  plac^  beside  the  relationship  line  and 
separated  by  a  slash,  7". 

A.2.4  Connection  Relationship  Semantics 

A  "specific  connection  relationship"  is  an  association  or  connection  between  entities  in  which  each 
instance  of  the  parent  entity  is  associated  with  zero,  one,  or  more  instances  of  the  child  entity,  and  each 
instance  of  the  child  entity  is  associated  >vith  exactly  one  instance  of  the  parent  entity.  For  exan^le,  a 
specific  connection  relationship  would  exist  between  the  entities  EMPLOYEE  and  DEPENDENT,  if  an 
EMPLOYEE  Has  z£ro,  one,  or  more  DEPENDENT  and  each  DEPENDENT  instance  is  associated  with 
a  single  EMPLOYEE. 

The  connection  relationship  may  be  further  defined  by  specifying  the  cardinality  of  the  relationship.  That 
is,  the  specification  of  how  many  child  entity  instances  may  exist  for  each  parent  instance.  Within 
IDEFIX,  the  following  relationship  cardinalities  can  be  expressed; 

1.  Each  parent  entity  instance  may  have  zero,  one  or  more  associated  child  entity  instances. 

2.  Each  parent  entity  instance  must  have  at  least  one  or  more  associated  child  entity  instances. 

3.  Each  parent  entity  instance  can  have  none  or  at  most  one  associated  child  instance. 

4.  Each  parent  entity  instance  is  associated  with  some  exact  number  of  child  entity  instances. 

If  an  instance  of  the  child  entity  is  identified  by  its  association  with  the  parent  entity,  then  the  relationship 
is  refened  to  as  an  "identifying  relationship" .  For  example,  if  one  or  more  tasks  are  associated  with  each 
project  and  tasks  are  only  uniquely  identified  within  a  project,  then  an  identifying  relationship  would  exist 
between  the  entities  PROJECT  and  TASK.  That  is,  the  associated  project  must  be  known  in  order  to 
uniquely  identify  one  task  from  all  other  tasks.  (Also  see  Foreign  Keys  Semantics.) 

If  every  instance  of  the  child  entity  can  be  uniquely  identified  without  knowing  the  associated  instance  of 
the  parent  entity,  then  the  relationship  is  referred  to  as  a  "non-identifying  relationship".  For  example, 
although  an  existence-dependency  relationship  may  exist  between  the  entities  EMPLOYEE  and 
DEPENDENT,  EMPLOYEES  may  be  uniquely  identified  by  its  key  set  without  identifying  the  associated 
DEPENDENT  instances. 

A  specific  connection  relationship  is  depicted  as  a  line  drawn  between  the  parent  entity  and  the  child  entity 
with  a  dot  at  the  child  end  of  the  line.  The  default  child  cardinality  is  zero,  one  or  many.  A  "P"  (for 
positive)  is  placed  beside  the  dot  to  indicate  a  cardinality  of  one  or  more.  A  ”Z"  is  placed  beside  the  dot 
to  indicate  a  cardinality  of  zero  or  one.  If  the  cardinality  is  an  exact  number,  a  positive  integer  number 
is  placed  beside  the  dot.  See  Figure  A-8. 
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Notation: 

Meaning: 

i 

Zero,  one  or  many. 

1  p 

One  or  more.  stands  for  positive. 

1  z 

Zero  or  one. 

i  3 

A  specific  quantity. 

1 

A  range  of  quantities. 

1 

Exactly  one. 

Figure  A-8.  Relationship  Cardinality  Syntax 


A  solid  line  depicts  an  identifying  relationship  between  the  parent  and  child  entities.  See  Figure  A-9. 
If  an  identifying  relationship  exists,  the  child  entity  is  always  an  dq)endent  entity,  represented  by  a 
rounded  comer  box,  and  the  primary 
key  attributes  of  the  parent  entity  are 
also  inherited  primary  key  attributes 
of  the  child  entity.  (Also  see  Foreign 
Keys  Semantics). 

The  parent  entity  in  an  identifying 
relationship  will  be  independent  unless 
the  parent  entity  is  sdso  the  child 
entity  in  some  other  identifying 
relationship,  in  which  case  both  the 
parent  and  child  entity  would  be 
identifier-dependent.  An  entity  may 
have  any  number  of  relationships  with 
other  entities.  However,  if  the  entity 
is  a  child  entity  in  any  identifying 
relationship,  it  is  always  shown  with 
rounded  comers,  regardless  of  its  role 
in  the  other  relationships. 

A  dashed  line  depicts  a 
non-identifying  relationship  between 
the  parent  and  child  entities.  See 
Figure  A- 10.  Both  parent  and  child 
entities  will  be  identifier-independent 
entities  in  a  non-identifying  relationship  unless  either  or  both  are  child  entities  in  some  other  relationship 


Figure  A-9.  Identifying  Relationship  Syntax 
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which  is  an  identifying  relationship. 

A  relationship  is  a  verb  or  verb  phrase  placed  beside  the  relationship  line.  The  name  of  each  relationship 

between  the  same  two  entities 
must  be  unique,  but  the 
relationship  names  need  not 
be  unique  within  the  model. 
The  relationship  name  is 
always  expressed  in  the 
parent-  to-child  direction, 
such  that  a  sentence  can  be 
formed  by  combining  the 
parent  entity  name, 
relationship  name,  cardinality 
expression,  and  child  entity 
name. 

For  example,  the  statement 
"A  project  consists  of  one  or 
more  tasks"  could  be  derived 
from  a  relationship  showing 
PROJECT  as  the  parent 
entity,  TASK  as  the  child 
entity  with  a  "P"  cardinality 
symbol,  and  "Consists-oC  as 
the  relationship  name.  Note 
that  the  relationship  must  still 
hold  true  when  stated  from 
the  reverse  direction, 
although  the  child  to-parent 
relationship  is  not  named 
explicitly.  From  the  previous 
example,  it  is  inferred  that  "a 
task  is  part  of  exactly  one 
project." 


ORGANIZATION 


Parent  Entity 


employs  | 

EMPLOYEE 


Non-identifying 

Relationship 


\ 


Child  Entity 


Figure  A- 10.  Non-Identifying 
Relationship  Syntax 


A. 2.5  Categorization  Relationship  Semantics  (Category  Entities) 

Entities  are  used  to  represent  the  notion  of  "things  about  which  we  need  information.”  Since  some  real 
world  things  are  categories  of  other  real  world  things,  some  entities  must,  in  some  sense,  be  categories 
of  other  entities.  For  example,  suppose  employees  are  something  about  which  information  is  needed. 
Although  there  is  some  information  needed  about  all  employees,  additional  information  may  be  needed 
about  salaried  employees  that  is  different  from  the  additional  information  needed  about  hourly  employees. 
Therefore,  the  entities  SALARIED-EMPLOYEES  and  HOURLY-EMPLOYEES  are  categories  of  the 
entity  EMPLOYEE.  In  an  IDEFIX  model,  they  are  related  to  one  another  through  a  categorization 
relationship. 

Category  entities  for  a  generic  entity  are  always  mutually  exclusive.  That  is,  an  instance  of  the  generic 
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EMPLOYEE 


Generic  Entity 


Discriminator 


Q  Employ— -Typa 


r - 

SALARIED-EMPLOYEE 


T. 


- ^ 

HOURLY-EMPLOYEE 


\  / 


Category  Entities 


Figure  A-11.  Category 
Relationship  Syntax 


entity  can  correspond  to  the  instance 
of  only  one  category  entity.  In  the 
example,  this  implies  that  an 
employee  cannot  be  both  salaried 
and  hourly. 

An  attribute  in  the  generic  entity 
instance  determines  to  which  of  the 
possible  category  entities  it  is 
related.  This  attribute  is  called  the 
”  discriminator  ”  of  the  categorization 
relationship.  In  the  example,  the 
discriminator  might  be  named 
EMPLOYEE-TYPE.  The  name  of 
the  generic  entity  attribute  used  as 
the  discriminator  is  written  beside 
the  circle. 

Category  entities  are  also  always 
identifier -dependent.  See  Figure  A- 
11.  The  generic  entity  may  be 
either  independent  or  dependent. 


A.2.6  Attribute  Semantics 

An  "attribute"  represents  a  type  of  characteristic  or  property  associated  with  an  entity.  An  "attribute 
instance"  is  a  specific  characteristic  of  an  individual  member  of  the  set.  An  attribute  instance  is  defined 
by  both  the  type  of  characteristic  and  its  value,  referred  to  as  an  "attribute  value."  An  instance  of  an 
entity,  then,  must  have  a  single  specific  value  for  each  associated  attribute.  For  example, 
EMPLOYEE-NAME  and  EMPLOYEE-BIRTH-DATE  may  be  attributes  associated  with  the  entity 
EMPLOYEE,  and  could  have  the  attribute  values  of  "Mary  Jones"  and  "February  27,  1953." 

An  entity  must  have  an  attribute,  or  set  of  attributes,  whose  values  uniquely  identify  every  instance  of  the 
entity.  These  attributes  form  the  "primary-key"  of  the  entity.  For  example,  the  attribute 
EMPLOYEE-IDENTIFIER  might  serve  as  the  primary  key  for  the  entity  EMPLOYEE,  while  the 
attributes  EMPLOYEE-NAME  and  EMPLOYEE-BIRTH-DATE  would  be  non-key  attributes. 

Within  an  IDEFIX  model,  every  attribute  is  owned  by  only  one  entity.  In  addition  to  attributes  "owned" 
by  the  entity,  an  attribute  may  be  "inherited"  by  the  entity  through  a  specific  connection  or  categorization 
relationship  in  which  it  is  a  child  or  category  entity.  For  example,  if  every  employee  is  assigned  to  a 
department,  then  the  attribute  DEPARTMENT-NUMBER  could  be  an  attribute  of  EMPLOYEE  which 
migrates  through  the  relationship  of  the  entity  EMPLOYEE  to  the  entity  DEPARTMENT.  The  entity 
DEPARTMENT  would  be  the  owner  of  the  attribute  DEPARTMENT-NUMBER. 

Only  primary  key  attributes  may  be  inherited  through  a  relationship.  The  attribute 
DEPARTMENT-NAME,  for  example,  would  not  be  an  inherited  attribute  of  EMPLOYEE  if  it  was  not 
part  of  the  primary  key  for  the  entity  DEPARTMENT. 

Each  attribute  is  identified  by  a  unique  name  expressed  '  noun  or  noun  phrase  that  describes  the 
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characteristic  represented  by  the  attribute.  The  noun  phrase  is  singular,  not  plural  and  should  end  with 
a  class  word.  Class  words  are  those  descriptors  that  indicate  what  type  of  values  should  "hC  in  the 
attribute.  Class  word  examples  include  "DATE",  "TYPE",  "IDENTIFIER",  "NAME"  and 
"QUANTITY".  The  attribute  name  must  be  meaningful  and  consistent  throughout  the  model.  A  formal 
definition  of  the  attribute  and  a  list  of  synonyms  or  aliases  must  be  defined  in  the  model  of  glossary. 
Attributes  are  shown  by  listing  their  names,  one  line  per  attribute,  inside  the  associated  entity  box. 

A.2.7  Primary  Key  Semantics 

The  Primary  Key  oi  an  entity  is  one  or  more  attributes,  whose  value  uniquely  identifies  every  instance 
of  the  entity.  For  example,  the  attribute  PURCHASE-ORDER-NUMBER  may  uniquely  identify  an 
instance  of  ie  entity  PURCHASE-ORDER.  A  combination  of  the  attributes  ACCOUNT-NUMBER  and 
CHECK-  NUMBER  may  uniquely  identify  an  instance  of  the  entity  CHECK. 

Attributes  which  define  the  primary  key  are  placed  at  the  top  of  the  attribute  list  within  an  entity  box  and 
separated  from  the  other  attributes  by  a  horizontal  line.  See  Figure  A-12. 


Figure  A-12.  Attribute  and  Primary  Key  Syntax 
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2.8  Foreign  Key  Semantics 


If  a  specific  connection  or  categorization  relationship  exists  between  two  entities,  then  the  key  attributes 
of  the  parent  or  generic  entity  migrate  to  the 
child  or  category  entity.  These  inherited 
attributes  are  referred  to  as  "Foreign  Keys." 
for  example,  if  a  connection  relationship  exists 
between  the  entity  EMPLOYEE  as  a  parent 
and  the  entity  DEPENDENT  as  a  child,  then 
the  primary  key  attributes  of  EMPLOYEE 
would  be  inherited  attributes  of  the  entity 
DEPENDENT.  In  this  exanq)le,  illustrated  in 
Figure  A-13,  the  parent  key  attribute, 

EMPLOYEE-NUMBER,  would  migrate  to  the 
child  entity  DEPENDENT.  An  inherited 
attribute  may  be  used  as  either  a  portion  or 
total  primary  key,  alternate  key,  or  non-key 
attribute  within  an  entity. 


A  foreign  key  is  shown  by  placing  the  names 
of  the  inherit^  attributes  inside  the  child  entity 


Pnnw/yK0y 


EMPLOYEE 


Emptov«-Nuw»«i 


EmployM-Nanw 
Soeial-S*cunty-Numbar 
Employ—  Marttol-SMtm 


DEPENDENT 


Efflployoo-Numter  (FK)< 
Deoandent-Klame 


Oop«nd«nl-Oato-of-Siith 


Idpntlfwtna  RpIiBobiHIp: 
Tha  Primary  Kay  of  ttia 
Parant  Entity  mlgrataa  to 
Kay  position  In  tha 
Child  Entity. 


FomgnKmf 


Figure  A-13.  Key  Migration  in 
Identifying  Relationships 


1  Primary  Kay 

1  PART 

Part-Numbar  ^ 

Pan-Hama 

Invantery^Quantity 

Non-idanWvIna  RdlatlonshiD: 

1 

1  «-ord«r8C}-an 

LINE-4TEM 

The  Primary  Kay  of  tha 

Parent  Entity  migrates  to 
Non-key  position  In  the 

Child  Entity. 

f  Lina-ttam-Numbar 

Ordar^Numbar  (FK) 

Part^iumbar  (FK) 

Qtianttty-Ordarad 

Foraign  Kay 

Figure  A-14. 

Key  Migration  in 

Non-Identifying  Relationships 


box  and  by  following  each  with  the  letters  "FK" 
in  parentheses,  i.e.,  "(FK)".  If  the  inherited 
attribute  belongs  to  the  primary  key  of  the  child 
entity,  it  is  placed  above  the  horizontal  line  and 
the  entity  is  drawn  with  rounded  comers  to 
indicate  that  the  identifier  (primary  key)  of 
entity  is  dependent  upon  an  attribute  inherited 
through  a  relationship.  If  the  inherited  attribute 
does  not  belong  to  the  primary  key  of  the  child 
entity,  it  is  drawn  below  the  line.  See  Figure 
A-14. 

In  a  categorization  relationship,  both  the  generic 
entity  and  the  category  entities  rqpresent  the 
same  real-world  thing.  Therefore,  ^e  primary 
key  for  all  category  entities  is  inherited  through 
the  categorization 


relationship  from  the  primary  key  of  the  generic 
entity.  For  example,  if 
SALARIED-EMPLOYEE  and  HOURLY-EMPLOYEE  are  category  entities  and  EMPLOYEE  is  the 
generic  entity,  and  the  attribute  EMPLOYEE-NUMBER  is  the  primary  key  for  the  entity  EMPLOYEE, 
it  would  also  be  the  primary  key  for  the  category  entities  SALARIED-EMPLOYEE  and 
HOURLY-EMPLOYEE. 
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A.2.9  Role  Named  Relationships 


In  some  cases,  a  child  entity  may  have  multiple 
relationships  to  the  same  parent  entity.  The  primary 
key  of  the  parent  entity  would  appear  as  inherited 
attributes  in  the  child  entity  for  each  relationship.  For 
a  given  instance  of  the  child  entity,  the  value  of  the 
inherited  attributes  may  be  different  for  each 
relationship,  i.e.  two  different  instances  of  the  parent 
entity  may  be  referenced.  When  a  single  attribute  is 
inherited  more  than  once,  a  "role  name"  is  assigned  to 
each  occurrence.  Role  names  are  shown  in  the  child 
entity  as  a  prefix  followed  by  a  period  (" . ")  in  front  of 
each  attribute  in  the  role.  For  example,  an  instance  of 
INDIVIDUAL  may  propose  an  agreement,  and  another 
instance  of  INDIVIDUAL  accept  that  agreement.  The 
instance  of  AGREEMENT  would  require  the 
Figure  A-15.  Role  Named  Relationships  INDIVIDUAL-NUMBER  that  uniquely  identifies  both 

instances  of  INDIVIDUAL.  This  example  is  depicted 
in  Figure  A-15. 


INDIVIDUAL 


Individual-No 


Individual-Name 

Social-Security-Number 

Individual-Marital-Status 


propoMs 


AGREEMENT 


accepts 


Proposing-Individual  No.Irdividual-No  (FK) 
Accepting-Individual  No. Individual-No  (FK) 


A.2.10  Creating  IDEFIX  Data  Models 

The  following  depicts  a  generalized  flow  in  the  development  of  IDEFIX  data  models. 

Step  1  -  Entity  Definition 

A  candidate  entity  pool  and  definitions  are  developed  as  the  first  step  in  modeling.  Additional 
entities  will  be  added  throughout  the  modeling  process  and  the  definitions  will  be  refined. 

Step  2  •  Relationship  Definition 

The  next  step  is  identification  of  a  preliminary  set  of  relationships  between  the  candidate  entities. 
The  model  glossary  is  expanded  to  include  relationships  as  well  as  entity  definitions.  The  primary 
output  of  this  Step  is  one  or  more  entity-relationship  level  diagrams.  At  this  stage  of  modeling, 
all  entities  are  shown  as  square  boxes,  no  attributes  are  shown,  and  non-specific  (many-to-many) 
relationships  are  permitted. 

The  entity-relationship  data  model  provides  a  stepping  stone  to  the  final,  fully  attributed  data  model. 
Since  model  building  is  a  top-down  approach,  the  entity-relationship  model  represents  the  broadest 
level  to  be  considered  in  a  data  modeling  project.  It  is  useful  at  the  planning  level  because  it  helps 
define  initial  business  statements  that  represent  constraints  in  the  environment.  It  also  aids  in 
defining  and  validating  data  requirements. 

The  entity-relationship  data  model  allows  you  to  focus  on  some  of  the  details  at  a  time  -  in  this 
case,  entities  and  their  relationships  -rather  than  having  to  deal  with  a  large  amount  of  detail 
(characteristics  of  the  objects  and  relationships)  at  once.  The  result  is  a  reasonably  digestible 
amount  of  information,  which  facilitates  good  data  modeling. 


Step  3  -  Key  Definitions 

The  objectives  of  Step  3  are  to  refine  non-specific  relationships,  define  key  attributes  for  each 
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entity,  migrate  primary  keys  to  establish  foreign  keys,  and  validate  relationships  and  keys.  The 
primary  result  of  this  step  is  one  or  more  key-based  model  diagrams.  The  key-based  model  depicts 
primary,  alternate,  and  foreign  key  attributes.  Non-key  attributes  may  not  be  shown,  as  desired. 
A  key-based  model  distinguishes  between  dependent  and  independent  entities  and  between 
identifying  and  non-ideutifying  relationships.  Role  names  and  path  assertions  are  also  specified. 
Non-specific  (many-to-many)  relationships  are  not  allowed  at  this  level. 

At  the  key-based  level,  the  focus  is  on  identifying  the  key  attributes  --  those  charaaeristics  and 
properties  of  the  data  that  uniquely  identify  one  entity  instance  from  another.  The  key -based  data 
model  is  a  more  precise  representation  of  the  data  in  the  environment.  The  concept  of  key 
attributes  is  introduced  as  a  more  rigorous  test  for  identifying  real  entities.  Foreign  keys  are  used 
to  validate  the  identified  relationships  and  to  ensure  that  they  make  sense.  A  key -based  data  model 
may  be  used  to  begin  the  integration  of  a  topical  view  with  a  broader  view. 

Step  4  •  Attribute  Definition 

The  final  state  of  modeling  is  attribution.  The  objectives  of  this  step  are  to  define  non-key 
attributes,  establish  attribute  ownership,  and  validate  and  refine  the  data  structure.  The  result  of 
Step  4  is  one  or  more  fully  attributed  model  diagrams,  a  completed  glossary  of  entity,  relationship, 
and  attribute  definitions  and  narrative  statements  of  the  modeled  business  rules. 

Step  5  •  Model  Integration 

Fully  attributed  data  model  views  can  be  merged  to  provide  a  neutral,  integrated  data  model  of  a 
specified  subjea  area.  This  model  then  becomes  the  definition  of  conceptual  schema.  Since  it 
contains  all  the  attributes  of  the  specified  entities,  it  provides  a  complete  and  descriptive  view  of 
the  data  in  the  modeling  subjea  area,  thereby  resolving  any  ambiguity  that  may  have  existed  at  the 
other  levels.  Although  view  integration  can  actually  be  done  at  each  of  the  three  data  model  levels, 
it  is  the  fully  attributed  view  that  is  the  most  useful  in  moving  an  organization  to  an  integrated 
systems  environment. 

Because  the  fully  attributed  data  model  is  a  stable,  non-redundant,  integrated  view  of  data,  databases 
designed  ft’om  this  perspective  are  flexible  and  have  lengthy  life  cycles.  This  is  because  they  are 
based  on  stable  data  structures  rather  than  processes  that  frequently  change. 
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Appendix  B 
Activity  Descriptions 


This  section  provides  detailed  definitions  of  all  Capacity  Management  activities  identified  in  the 
Activity  Models.  Definitions  are  tailored  to  the  modeling  context  used  in  this  workshop. 

AO  Perform  Capacity  Management 

The  Cq)acity  Management  (CM)  Function  is  composed  of  five  primary  activities:  Manage  Service, 
Provide  Information,  Manage  Performance,  Pi^  Capacity,  and  Maintain  Capacity  Management 
Models.  The  CM  Function  provides  a  structured  framework  for  managing  the  performance  of 
Information  Systems,  networks,  and  communications  resources  (PC-to-Mainframe)  to  ensure  that:  (1) 
resources  are  sufficient  and  available  to  meet  defined  user  service-level  objectives  and  capacity 
requirements,  (2)  resource  utilization  is  cost-efficient,  effective,  and  well-  managed,  (3)  performance 
is  monitored,  measured,  and  evaluated  to  ensure  maintenance  of  required  performance  levels,  and  (4) 
workload  forecasts  are  made,  reserve  capacity  is  available,  and  all  security  requirements  are  met. 

Manage  Service  is  concerned  with  providing  support  for  customer  requirements,  providing  project 
management  and  tracking,  and  establishing  support  requirements  for  CM  activities. 

Provide  Information  is  comprised  of  three  activities  for  acquiring  data,  administering  data,  and 
providing  routine  reporting. 

Manage  Performance  conducts  performance  measurements,  monitors  performance,  performs 
benchmarking,  conducts  problem  diagnosis,  and  resolves  problems. 

Plan  Capacity  is  comprised  of  four  major  activities  for  capacity  analysis,  capacity  planning,  change 
management  recommendations,  and  the  development  of  networ^communication  interface 
requirements. 

Maintain  Capacity  Management  Models  has  three  major  activities  for  certifying  baseline  models, 
building  new  models,  and  validating  these  models. 

These  models  include  hardware  and  software  configuration  models,  performance  prediction  models, 
workload  configuration  models,  capacity  models,  and  any  other  "model”  that  may  be  generated  and/or 
used  by  the  CM  Function.  For  example,  some  models  may  be  used  to  perform  "what  iP  performance 
prediction.  Models  produced  by  configuration  management  will  also  be  used  by  the  Capacity 
Management  Function 
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A1  Manage  Service 


Manage  Service  is  comprised  of  three  main  activities;  Provide  Requirements  Support, 
Provide  Project  Management,  and  Establish  Support  Requirements.  Manage  Service  can 
best  be  described  as  a  "front  door"  of  the  CM  Function.  It  provides  an  interface  to  the 
Information  Processing  Center  (IPC),  Central  Design  Activity  (CD A),  or  other  management 
structures  for  providing  support  for  performance  or  capacity  planning  issues  in  meeting  user 
requirements  and  service  level  objectives,  as  well  as,  performance  measurement  or  modeling 
activities. 

These  CM  support  requirements,  etc.,  are  determined  by  a  specific  organizational  element 
(e.g.,  CDA/IPC,  application  division,  conununications  and/or  network  divisions,  etc.,  with  the 
assistance  of  the  CM  staff  as  pertains  to  performance  and  feasibility  issues),  or  customer 
service  unit  that  works  with  the  CM  staff,  to  ensure  user  support  requirements  (e.g.,  service 
level  objectives,  etc.)  can  be  met,  and  that  user  objectives  are  meaningful  and  measurable. 

The  primary  purpose  of  the  Manage  Service  function  is  to  ensure  that  all  measures, 
configuration  changes,  performance  software,  version  upgrades,  network  and  communications 
requirements  are  registered  Cogged  in)  in  the  on-line  project  management  and  tracking 
systems,  analyzed  for  feasibility,  and  forwarded  for  entry  into  the  on-line  project  management 
tracking  system  where  they  will  eventually  be  submitted  to  the  iq>propriate  CM  area  in  the 
form  of  a  work  assignment. 

All  Provide  Requirements  Support 

The  interface  to  the  DII/IS  Capacity  Management  function  that  provides  "help  desk" 
liaison  and  feedback  on  performance  measurement  and  forecasting  activities  to  a 
requestor  (e.g. Megacenter).  In  addition,  this  activity  also  registers  the  request, 
determines  the  feasibility,  and  passes  the  request  for  input  to  the  on-line  project 
management  system  for  further  action. 

Alll  Register  Request 

Records  the  CM/CDA  requirement,  configuration  change  request,  and  help 
desk  problem  into  a  requirements  support  registration  log.  This  registered 
request  is  then  provided  for  input  to  the  on-line  project  management  and 
tracking  system. 

A112  Determine  Feasibility  of  Request 

Determines  the  feasibility  of  executing  the  Service  Level  Objectives  (SLO)  by 
performing  a  preliminary  analysis  of  stated  specifications,  standards,  resource 
and  performance  requirements,  etc.  This  includes  a  review  for  completeness, 
and  identification  of  performance  metrics  and  resources  required  for  servicing 
the  request  within  a  specified  time  frame.  This  provides  the  basis  for 
performing  a  feasibility  analysis  by  the  Manage  Performance  Activity  (A3). 
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A 113  Provide  Support  Liaisoo 


Provides  a  focal  point  'front  door"  to  the  CM  Function.  This  includes 
working  with  the  CDA's.  IPCs.  etc,  to  provide  performance  requirements 
support  (as  i^ropriate)  for  current  and  future  needs. 


A12  Provide  Project  Management 

Accepts  all  requests  (projects)  for  CM  services  (including  requests  for  feasibility 
analysis),  assigning  work  to  the  appropriate  areas  for  action,  developing  project  plans, 
timeliner  Jid  reporting  CM  operating  costs.  All  projects  and  related  tasks  will  be 
tracked  through  an  on-line  project  management  system. 

A121  Perform  Project  Planning 

Translates  service  requirements  (SLOs)  into  project  action  plans,  and  enters  all 
requests  for  services  into  a  project  management  system.  All  projects  are 
tracked  throughout  execution  to  completion.  Access  to  the  status  of  each 
project  is  available  on-line  for  IPC  and  CDA  personnel. 

A122  Perform  Requirements  Analysis 

Performs  a  review  of  project  plans  and  develops  work  assignments  for  the 
appropriate  CM  functional  area  that  will  execute  the  support  requirement. 

Data  for  preparing  CM  operating  cost  reports  are  prepared  in  this  function. 

A123  Schedule  Projects 

Develops  a  time  schedule  (milestones)  for  executing  each  projea  tasked  to  the 
CM  Function,  and  tracks  this  schedule  using  an  on-line  project  management 
system. 

A13  Establish  Support  Requirements 

Collects  support  requirements  (e.g.  staffing  and  training  needs,  financial  needs, 
hardware/software  requirements,  etc.)  needed  to  sustain  the  CM  Function  and 
develops  the  overall  CM  request  for  support  to  management.  These  requirements  will 
cover  all  areas  of  the  CM  Function. 
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A131  Prepare  Financial  Support  Rqmts 


Reports  the  financial  resources  (e.g.,  fiinding,  etc.)  needed  by  the  CM  stafi^  to 
perform  the  CM  Function.  This  includes  the  fimds  necessary  to  support 
staffing,  training,  contracts,  etc.  This  repon  translates  the  financial  support 
requirements  into  a  formal  request  to  higher  management  (e.g..  Megacenter, 
IPC,  CDA,  etc.). 

A132  Establish  Staff  Support  Rqmts 

Establishes  the  personnel  resources  required  by  the  CM  staff  to  perform  the 
CM  Function.  This  includes  a  position  description  of  the  type  of  skill  set 
required  for  each  functional  position  in  the  CM  Function,  with  supporting 
information  such  as  skill  levels,  ratio  of  on-board  personnel  vs.  positions 
required,  etc. 

A133  Establish  Training  Support  Rqmts 

Identifies  short-range  and  long-range  training  requirements  necessary  to 
support  the  CM  Fimction.  This  includes  a  description  of  the  CM  staff  training 
requirements  necessary  for  the  successful  execution  of  work  assignments. 

A134  Establish  Contractual  Support  Rqmts 

Detemtines  the  contractual  support  (e.g.,  consultant  staff,  performance  staff, 
network  and  communications  staff,  equipment,  maintenance,  software  support, 
vendor  services,  etc.)  required  to  perform  the  CM  Function. 

A2  Provide  Information 

Provide  Information  is  the  area  of  CM  that  maintains  a  central  CM  information/DII/IS 
model  database.  The  Provide  Information  activity  provides  information  for  the  generation  of 
standard  and  ad  hoc  reports,  and  cost  information  on  resource  utilization  for  CM  performance 
and  planning  activities  for  the  information  system  environment.  It  also  provides  a  central 
source  (e.g.,  CM  information/DIIAS  model  database)  for  the  maintenance,  distribution,  or 
reporting  of  CM  information.  This  activity  collects  data/model  information  received  from  all 
performance  and  capacity  planning  activities,  and  works  in  conjunction  with  the  Manage 
Service  Activity  (Al).  This  Activity  also  receives  tasking  from  the  Manage  Service  Activity 
(Al)  and  transfers  the  tasking  information  into  an  on-line  project  management  and  tracking 
system. 


A21  Acquire  Data 

Collects  and  screens  (e.g.,  tests  for  invalid  records,  missing  records,  etc.)  data 
necessary  to  enable  the  analysis  of  performance  and  services  provided. 
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A22  Administer  Data 


Ensures  the  data  collected  is  valid,  complete,  comprdiensive,  accur^,  and  represents 
all  operational  activities. 

A23  Provide  Routine  Reporting 

Documents  the  achievement  level  of  performance  activities  against  defined  service 
level  objectives.  Provides  periodic  reports  to  various  levels  of  internal  and  external 
management. 

A3  Manage  Performance 

Measures,  evaluates,  and  r^rts  on  information  system  performance  to  assess  current 
performance  levels.  Identifies  and  recommends  adjustments  that  are  designed  to  in4>rove 
performance.  This  activity  provides  input  to  the  Plan  Capacity  Activity  (A4)  to  d^ermine 
fiiture  ct^acity  requirements.  It  also  promts  problem  diagnosis  and  resolution. 

A31  Measure  Performance 

Retrieves/collects  and  analyzes  data  to  determine  performance  levels  of  all  systems  and 
conqx)nents  (e.g..  mainframes,  communication  systems,  networks).  Measurements 
include  system  utilization,  memory  storage,  disk  usage,  bandwidth  and  channel 
capacity,  detected  faults,  addressing  errors,  bit-error  rates,  etc. 

A311  Establish  Measurement  nan 

Defines  the  goals  and  objectives  for  measuring  specific  conqionents  of  the 
Dn/IS  configuration.  This  includes  (1)  identification  of  systems  and 
components  to  be  measured  ,  (2)  performance  targets  and  thresholds  to  be 
met,  and  (3)  specific  metrics  to  be  used  to  measure  achievement  of 
performance  objectives.  The  plan  includes  a  determination  of  which  specific 
tools  and  data  extraction  or  manipulation  routines  are  needed  to  perform  the 
measurements. 

Any  performance  excq}tions  received  from  Determine  Performance 
Exceptions  Activity  (A322)  must  be  must  be  corrected  prior  to  producing 
performance  management  rqx>rts  from  Activity  Generate  Performance 
Reports  (A323). 

Performance  exceptions  for  incomplete,  unclear,  or  insufficient  measurement 
data  may  be  caus^  by  erroneous  measurements  or  measurement  criteria. 

These  criteria  must  be  corrected  prior  to  producing  performance  management 
reports  fi'om  Generate  Performance  Reports  Activity  (A323). 
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A3111  Determine  Components  to  be  Measured 

Determines  the  Dll/lS  system,  mainframe,  network,  and 
communications  components  to  be  measured,  as  well  as,  the  capabiUty 
of  measuring  each  component.  Components  to  be  measured  are  those 
that  reflect  system  performance,  or  have  an  impact  (direct  or 
peripheral)  on  the  system  being  measured.  They  will  form  the  basis 
for  measuring  any  system  or  component  of  the  DII/IS  configuration. 


A3112  Establish  Performance  Metrics 

Determines  the  performance  measurement  criteria  (i.e.,  metrics)  that 
are  used,  or  are  appropriate,  to  represent  the  performance  of  the 
system  components  previously  identified  and  being  measured.  Since 
there  can  be  more  than  one  measurement  criterion  for  a  specific 
component,  it  is  necessary  to  establish  comprehensive  and 
representative  sets  of  metrics  for  each  component,  and  to  ensure  that 
metrics  are  established  to  measure  the  performance  of  all  DII/IS 
system  components. 

A3113  Identify  Performance  Targets  and  Thresholds 

To  foster  accurate  analysis  of  system  components,  by  identifying 
specific  target  goals,  and  acceptable  thresholds,  to  ensure  efficient  and 
effective  performance  and  operations.  These  targets  and  thresholds  for 
the  measured  components  collectively  must  support  organizational 
performance  goals  and  objectives,  user  SLOs,  and  warfighter  mission 
requirements. 

A312  Retrieve  Selected  Data 

To  support  the  performance  measurement  process,  by  ensuring  that  sufficient 
data,  of  an  adequate  level  of  detail,  is  ctqttured  and  stored  for  retrieval  upon 
demand.  This  requires  the  use  of  data  collection  routines  and  software  for 
monitoring  and  measuring  the  performance  of  all  system  components.  The  data 
colleaed  must  be  stored  in  a  compatible  and  accessible  format. 
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A3 13  Conduct  Performance  Measurement 


Conducts  specific  performance  measurements  on  con^nents  of  the  DU/IS 
environment  using  established  and  related  metrics  .  Hiese  systems  or 
component  measurements  (e.g.,  memory  utilization,  CPU  busy,  bandwidth 
capacity,  response-time,  pon/hub  contention,  query  delays,  etc.)  and 
associated  metrics,  will  cover  mainframe,  communications,  and  network 
configurations.  The  established  criteria  used  must  ensure  that  C0D:^)arative 
analyses  can  reveal  whether  or  not  the  system  or  conqwnent  is  performing  at 
acceptable  levels  (e.g.,  meeting  SLOs,  established  targets  and  thresholds, 
etc.). 

A32  Monitor  Performance 

Monitors  acmal  performance  levels  against  defined  target  objectives.  This  activity 
identifies  performance  problem  exceptions  for  action  and  resolution.  Performance 
exceptions  may  also  be  caused  by:  incomplete,  unclear,  or  insufficient  measurement 
data.  These  exceptions  are  fed  back  to  Activity  Establish  Measurement  Plan  (A31 1) 
for  further  action.  Exceptions  to  measurements  or  measurement  criteria  must  be 
corrected  prior  to  producing  performance  management  reports. 

A321  Compare  Performance  with  Targets  and  Thresholds 

Receives  performance  measurement  data,  and  identified  components,  metrics, 
targets  and  thresholds  fi^om  the  Conduct  Performance  Measurement  Activity 
(A3 13),  and  compares  these  measurements  against  established  performance 
objectives  (i.e.,  targets  and  thresholds).  Examples  of  performance  data 
include:  utilization,  response  time,  transaction  processing  rates,  data  transfer 
rates,  I/O  throughput,  device  availability,  bit-error  rates,  bus  speed,  millions 
of  instructions  per  second  (MIPS),  etc. 

The  measurement  data  is  compared  against  the  SLOs,  vendor  component 
specifications  for  performance  levels  of  DII/IS  components  and  systems,  etc., 
to  produce  a  performance  comparison  report. 

A322  Determine  Performance  Exceptions 

Identifies  exceptions  where  actual  components  and  systems  (collections  of 
DII/IS  components)  have  exceeded  performance  measurement  thresholds.  For 
example,  if  the  threshold  SLO  for  user  response  time  is  two  seconds,  any 
measurement  of  response  time  greater  than  two  seconds  would  be  viewed  as  an 
exception.  Performance  exceptions  may  also  be  caused  by:  incomplete, 
unclear,  or  insufficient  measurement  data  or  other  criteria.  These  exceptions 
are  fed  back  to  the  Establish  Measurement  Plan  Activity  (A3 11)  for  further 
action.  These  exceptions  to  measurements  or  measurement  criteria  must  also 
be  corrected  prior  to  producing  performance  management  reports. 
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A323  Generate  Performance  Reports 


Generates  reports  on  a  variety  of  issues  relating  to  the  comparison  of 
performance  measurements.  These  reports  will  document  how  well  actual 
establi^ed  targets  and  thresholds  are  met  for  components  measured.  This 
activity  also  provides  exception  reports  that  assess  incomplete  con^nent 
measurements,  or  incidents  when  anomalies  have  occurmi  during  the 
measurement  process,  or  have  not  provided  sufficient  data  to  perform  a 
comparative  analysis. 

A33  Perform  Benchmarking 

Performance  testing  of  a  system  configuration,  component,  or  plication  environment 
that  evaluates  and  measures  performance  against  standards,  performance  metrics, 
vendor  specifications,  etc.  Further,  benchmarks  can  be  run  against  hardware/software 
components  or  applications  that  execute  on  a  DII/IS  environment.  A  benchmark 
provides  an  evaluation  or  comparison  of  performance  tests  for  information  systems 
and/or  application  programs  based  upon  specific  criteria  and  standards.  This  activity 
is  performed  in  order  to  better  understand  and  predict  performance  results  and  impacts 
on  an  operational  DII/IS  environment. 

An  example  of  benchmarking  could  be  the  evaluation  of  the  workload  of  one 
mainframe  or  network  environment  to  determine  the  sizing  requirements  and  other 
criteria.  This  benchmark  might  be  used  to  evaluate  the  potential  for  transfer  of  an 
application  to  another  environment  and  to  ensure  the  same  or  better  level  of  service 
can  be  maintained. 

A34  Conduct  Problem  Diagnosis 

Evaluates  and  diagnoses  performance  exceptions  and  identified  problems  (e.g.,  user 
complaints  to  Help  Desk),  to  ensure  satisfactory  resolution  and  achievement  of 
service-level  objectives.  Problem  diagnosis  is  passed  to  the  Conduct  Problem 
Resolution  Activity  (A35)  for  action. 

A35  Conduct  Problem  Resolution 

Evaluates  reported  problems/preliminary  diagnoses.  This  involves  developing 
and  evaluating  alternative  solutions  (including  costs),  and  recommending 
corrective  actions  that  should  be  taken  to  bring  performance  levels  and 
services  provided  up  to  acceptable  levels  of  performance. 
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A4  Plan  Capacity 

Determines  and  recommends  adequate  resources  to  meet  future  workloads  and  satisfy  SLOs. 
Analyzes  projected  workloads,  system  utilization,  and  reserve  capacity.  Based  on  this 
information,  generates  short  and  long  term  capacity  plans  and  provides  iq>ut  to  the 
Configuration  Management  Function.  This  activity  also  develops  adequate  plans  to  ensure  that 
performance  and  capacity  requirements  (including  components  and  configurations)  are 
identified,  which  will  aid  in  disaster  recovery  and  backup  in  the  event  of  catastrophic 
disruption  of  operations. 

A41  Analyze  Capacity 

Predicts  performance  of  user  requirements  and  projected  workloads  against  baseline 
and  alternative  hardware/software  configurations  to  satisfy  service  level  objectives. 

This  includes  analyzing  projected  workloads  and  reserve  capacity,  and  based  on  that 
information,  forecasting  the  resources  required  to  support  future  workloads. 

A411  Establish  Analysis  Approach 

Clarifies  the  study  requirements  and  planning  as  to  how  the  study  will  be 
conducted.  This  activity  also  identifies  modeling  parameters,  performance 
modeling  activities  to  produce  the  iq>proach  for  proceeding  with  the  modeling 
effort. 

A412  ID  User  Workload  Projections 

Translates  user  workload  projections  into  modeling  parameters  required  to 
perform  a  edacity  planning  study.  Works  with  forecast  information  to  ensure 
that  the  forecast  is  as  representative  and  accurate  as  possible. 

A413  Modify  Workload  Modeling  Parameters 

Modifies  the  appropriate  baseline  model  parameters  (e.g.,  workload 
transaction  arrival  rates)  to  reflect  the  forecasted  changes. 
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A414  Perform  Modeling  Modification  Analysis 

An  iterative  process  of  model  modification  and  evaluation  in  order  to  evaluate 
various  study  scenarios,  determine  causes  of  hardware  saturation,  evaluate 
various  hardware  options.  &c.  This  is  the  core  of  the  edacity  planning  study. 

A415  Conduct  Performance  Prediction  Impact  Analysis 

Analyzes  performance  predictions  for  alternative  modeled  scenarios  and  their 
impacts  on  DII/IS  configurations.  This  Activity  provides  information  on 
capacity  requirements,  performance  analysis,  projected  costs,  and  modeling 
shortfalls  and  results. 

A42  Develop  Capacity  Plans 

Prepares  a  formal  planning  report  which  describes  and  documents  the  results  of  the 
capacity  study.  This  document  spells  out  all  of  the  steps  taken  in  conducting  the 
capacity  analysis,  all  assumptions  made,  timelines,  alternatives,  conclusions  and 
recommendations . 

The  plan  addresses:  forecasting  of  workload  changes,  changes  in  workload  arrival 
rates  for  existing  workload;  resource  profiles,  transaction  volumes,  user  counts,  etc., 
for  new  workloads;  or  estimates  of  changes  in  the  resource  profile  of  an  existing 
workload.  This  could  also  include  both  application  workloads  and  system  software 
components. 

The  plan  also  addresses  disaster  recovery  and  backup  planning  contingencies  to  ensure 
that  performance  cs^jabilities  and  capacity  are  available  in  the  event  of  catastrophic 
disruption  of  operations. 

A43  Develop  Change  Recommendations 

Recommends  changes  to  information  systems  which  may  precipitate  changes  to  the 
baseline  configuration.  The  changes  will  be  documented  in  accordance  with 
Configuration  Control  Board  (CCB)  guidelines. 

A44  Develop  Network  Communication  Interface  Requirements 

This  activity  communicates  workload  predictions,  capacity,  and  performance 
requirements  affecting  network  capacity  for  DII/IS  environments.  This  information 
will  enable  effective  end-to-end  Capacity  Management.  These  requirements  are  the 
by-product  of  capacity  plaiming  studies.  Any  area  of  the  DII/IS  environment  may  be 
affected  by  these  requirements,  and  may  include  such  system  loads  as;  interactive 
transaction  volumes,  print  volumes,  bandwidth  requirements,  packet  transmission 
requirements,  etc. 
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A5  Maintain  Capacity  Management  Models 

Reviewing,  refining,  creating,  archiving  and  cataloging  models  of  current  DII/IS 
environment(s)  that  can  be  used  for  performance  evaluation  and  capacity  planning  studies. 
Cunent  Capacity  Management  models  of  the  DII/IS  will  be  available  to  provide  input  for 
comparative  evaluations  and  development  alternatives.  The  establishment  of  current  DII/IS 
iseline  models  is  accomplished  on  a  periodic  basis  (e  g.,  monthly,  quarterly,  etc.). 

ASl  Certify  Baseline  DII/IS  Models 

Evaluates  how  accurately  baseline  models  reflea  changes  in  the  current  DII/IS 
environment.  Analysis  reveals  what  changes,  if  any,  are  required  to  the  baseline 
models. 

ASl  Build  Baseline  DII/IS  Models 

Creates  a  new  baseline  model  to  refine  or  replace  an  existing  archived  model.  This 
process  is  used  when  the  baseline  model  no  longer  reflects  the  current  DII/IS 
environment. 

A53  Validate  Baseline  DII/IS  Models 

Compares  the  predicted  outcomes  of  newly  created  baseline  models  against  actual 
measurements  and  criteria  obtained  firom  the  DII/IS  environment.  Invalid  models  are 
sent  back  to  the  Build  Baseline  DII/IS  Models  Activity  (ASl)  for  modification. 
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Appendix  C 
ICOM  Definitions 


This  section  defines  the  primary  information  requirements  needed  to  support  the  cs^)acity  management 
function.  These  requirements  are  expressed  as  ICOM  (Inputs,  Controls,  Outputs  and  Mechanisms). 
These  definitions  represent  specifc  processes  used  in  the  models,  and  may  be  used  differently  outisde 
of  the  CM  Function  context. 

AdHoc  Performance  Analysis 

Performance  modeling  studies  performed  by  Capacity  Management  personnel  in  response  to  requests 
by  performance  management. 

Alert  Messages 

Messages  to  operational  Information  Processing  Center  (IPC)  management  to  alert  them  that  a 
threshold  has  been  or  is  on  the  verge  of  being  exceeded.  These  thresholds  can  apply  to:  Central 
Processing  Unit  (CPU),  Direct  Access  Storage  Device  (DASD),  or  number  of  users  logged  on. 

Application  for  Benchmarking 

An  information  system  component  or  software  program  that  is  evaluated  against  a  set  of 
hardware/software  criteria  and/or  architectures  using  a  standard  test  environment  and  standard 
performance  measurements. 

Baseline  Model 

A  modeling  representation  of  a  specific  system  to  include  the  configurations  of  baseline  DII 
Information  Systems  and  components  (including  coiiq>uters,  communications,  and  networks).  These 
models  include  hardware  and  software  configurations,  performance  prediction  models,  workload 
characterizations,  etc.  These  models  also  form  the  basis  for  documenting  DII/IS  components  and 
system  configurations  in  a  standard  manner  for  any  organization’s  inventory,  systc...  design,  or 
network  topology.  They  form  the  "baseline"  firom  which  other  modeling  activities  occur,  and  are  the 
starting  point  for  Plan  Capacity  Activity  (A4).  Ute  models  may  be  created  within  the  CM  Function 
or  provided  by  other  sources  (e.g.,  configuration  management). 

Baseline  Configuration 

A  detailed  description  (i.e.,  schematics,  specifications,  components,  etc.)  of  the  configuration  for  the 
current  DII/IS  environment  that  is  maintained  by  the  C^acity  Management  (CM)  Function  or 
organization.  These  descriptions  are  updated  on  a  regular  basis  (e.g.  monthly,  quarterly)  to  ensure  a 
current  data  base  for  maintenance  of  the  baseline  models. 
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Benchmark  Results 


Measurements  that  provide  an  evaluation  or  comparison  of  performance  tests  on  information  systems 
and/or  application  programs  which  are  based  upon  specific  criteria  or  standards. 

Benchmarks 

A  specific  set  of  hardware/software  criteria,  programs,  and/or  system  architectures  using  a 
standardized  test  environment  and  standardized  performance  measurements  (e.g.,  a  computer  program 
which  executes  a  pre-determined  set  of  instructions  intended  to  model  various  types  of  workloads  such 
as  Whetstone  and  Dhry stone  benchmarks.) 

Budget 

Allocated  money  amounts  proposed  for  implementation  of  a  capacity  plan. 

CM  Data/Models 

(1)  CM  Data 

Data  retrieved  from  the  CM  information/configuration  model  database.  The  CM 
information/configuration  model  database  contains  performance  data  collected  from  various 
software  monitoring  facilities,  system  traces,  and  benchmark  results,  (e.g.,  component 
utilization,  bandwidth,  DASD  response  time,  etc.) 

(2)  CM  Models 

Dn/IS  environment  models  retrieved  from  the  CM  information/configuration  model  database. 
The  baseline  models  are  generated  from  the  Maintain  Conflguration  Models  Activity  (A5). 

CM  Operating  Costs 

The  cost  of  performing  the  CM  Function  for  a  designated  time  interval  (monthly,  yearly,  etc.).  These 
costs  include:  salary  costs,  software  costs,  machine  costs,  etc.  The  information  in  these  reports 
provide  details  and  summaries  of  costs  necessary  to  ensure  efficient  and  effective  CM  function 
activities. 

CM  Function  Funding 

The  approved  budgeted  funds  that  are  available  for  executing  the  CM  Function. 

CM/CDA  Rqmts 

(1)  CM  Requirements 

Capacity  requirements  generated  from  sources  other  than  the  Central  Design  Activity  (CDA). 
(e.g.,  a  request  to  bring  another  1000  users  on-line  to  provide  access  to  an  application). 
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(2)  CDA  Requirements 

User  requirements  that  are  transformed  into  design  specifications  for  new  s^lications  or 
modifications  of  existing  applications. 

Capacity  Plans 

Formal  reports  that  describe  and  document  results  of  capacity  studies.  These  documents  spell  out  all 
of  the  steps  taken  in  conducting  a  capacity  analysis,  all  assunq>tions  made,  timeliness,  alternatives, 
rationale,  conclusions,  and  recommendations  for  satisfying  service  level  agreements/objectives  and 
customer  requirements.  These  plans  are  in  accordance  with  Information  Resource  Management  (IRM) 
planning  directives  &  policy,  and  support  the  IRM  planning  process. 

Change  Request  Work  Assignment 

Analysis  to  be  conducted  by  the  performance  management  staff  to  assess  the  intact  of  a  proposed 
configuration  change.  This  includes  on-line  communication  requests,  new  system  configurations,  etc. 

Collected  Data 

Raw  performance  data  (e.g.,  component  utilization,  bandwidth,  DASD  response  time,  etc.)  and  other 
CM  data  that  has  been  captured,  stored  and  made  available  for  use  by  the  CM  Function. 

Comparative  Analysis  Feedback 

The  results  of  analyses  that  reveal  comparisons  of  performance  measurements  for  Defense  Information 
Infrastructure/Information  Systems  (DIIAS)  components  against  defined  metrics  and  targets. 
Inconsistent,  inappropriate  and/or  incomplete  set  of  metrics  for  measuring  components  will  be 
revealed  in  this  analysis.  This  analysis  will  show  whether  the  criteria  must  be  altered  to  ensure  more 
credible  performance  measurement  results.  The  feedback  provides  the  Comparative  Analysis 
Feedback  report  for  the  operations,  performance  and  planning  functional  areas. 

Configuration  Change  Analysis  Report 

Documentation  on  the  results  of  an  analysis  by  the  performance  management  staff  on  the  impact  or 
feasibility  of  a  configuration  change  request.  The  report  is  submitted  to  the  Configuration  Control 
Board  (CCB)  for  further  action. 

Configuration  Change  Recommendations 

A  recommendation  to  change  the  baseline  configuration  (e.g.  hardware,  system  software,  etc)  to 
improve  its  performance  capability  to  meet  capacity  planning  workload  projections  submined  to  data 
center  configuration  management  for  review  and  action. 
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Configuration  Change  Request 


Request  to  make  a  change  in  the  baseline  configuration.  The  change  request  will  be  documented  aiKl 
controlled  in  accordance  with  the  CCB  policy  and  guidelines. 

CCB  Approval 

An  action  by  the  CCB  that  approves  changes  to  the  DBAS  configuration.  This  is  a  requirement  for 
any  change  proposed  to  any  DII/IS  configuration.  (If  aj^roval  is  not  granted,  the  recommended 
ch^e  will  not  be  installed.) 

Contract  Vehicles 

These  are  contracts  available  to  provide  timely  procurement  capabilities  for  information  technology 
resources  required  to  support  the  CM  Function.  There  are  a  variety  of  contract  vehicles  that  can  be 
used,  as  well  as,  procurement  processes.  Most  of  these  vdiicles  have  limitations  on  dollar  or  quanity 
amounts,  bidding  processes,  etc. 

Contractors 

Private  sector  representatives  and  other  government  agency  personnel  who  assist  in  conducting  CM 
Functions. 

Design  Change  Recommendations 

Recommendations  to  change  the  performance  characteristics  of  an  software  plication  design  based 
on  analysis  of  its  performance.  These  recommendations  are  provided  to  the  IPC's,  CDA’s,  or 
appropriate  developers  for  consideration. 

DoD  CM  Technical  Personnel 

Personnel  included  in  the  following  categories: 

•  Communications  (e.g.,  long-haul.  Fiber  Distributed  Data  Interface  (FDDI),  Asynchronous 
Transfer  Mode  (ATM),  etc.)  personnel 

•  Local  Area  Network/Wide  Area  Network  (LAN/WAN/Client  Server)  personnel 

•  Mainframe  personnel 

•  Network  (e.g..  Systems  Network  Architecture  (SNA),  etc.)  personnel 
DoD  Support  Personnel 

DoD  personnel  who  provide  support  functions  (e.g.,  acquisition,  budget,  business  management, 
economic  analysis,  etc.)  to  the  CM  Function. 
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Executable  Model 


A  Dn/IS  component  or  system  model  whose  modeling  parameters  have  been  changed/modified  to 
represent  all  aspects  and  characteristics  of  a  projected  new  or  changed  workload.  When  this  model  is 
processed  (executed),  forecasts  of  DU/IS  component  utilizations  and  levels  of  performance  will  be 
generated. 

Executive  Level  Reports 

Reports  that  are  prepared  for  senior-level  officials  (e.g.  Defense  Information  Services  Organization 
(DISO),  Defense  Information  Systems  Agency  (DISA),  Deputy  Assistant  Secretary  of  Defense 
(Information  Management)  DASD  (IM),  Command,  Control,  Communications  and  Intelligence  (C3I), 
etc.)  that  preside  over  the  CM  Function  for  all  DII  systems.  These  reports  contain  summarized 
information  that  present  a  concise  discussion  of  major  CM  Functions,  as  is  required  or  requested. 
Areas  of  discussion  may  include: 

•  performance  utilization 

•  current  and  reserve  capacity 

•  workload  growth 

•  throughput  evaluation 

•  number  of  user  requests  for  service 

•  number  of  problems  encountered 

•  issues  that  need  resolution:  procurement  requirements,  security  concerns,  staffing  concerns, 
funding  concerns,  etc. 

These  reports  may  be  provided  on  a  daily,  weekly,  monthly  or  other  frequency,  as  required. 

Facilities  and  Equipment 

The  resources  that  support  CM  staff  in  performing  the  CM  Function.  These  resources  include: 
computer  systems,  hardware,  software,  networks,  communication  capabilities,  tools,  test  equipment, 
etc. 

Feedback  Information 

Information  to  the  CDA  community  and  data  center  management  providing  such  information  as  how 
well  service  level  objectives  are  being  met,  the  status  of  actions  being  taken  by  CM  to  resolve, 
problems,  problem  resolutions,  etc.  The  feedback  information  report  is  produced  for  the  operations 
and  performance  functional  areas. 

Forecasted  Capacity  Rqmts 

The  results,  after  performing  capacity  analysis,  that  represent  customer  or  system  workload 
projections,  presented  as  resource  requirements  satisfying  performance  criteria. 

Help  Desk  CM  Problem 
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A  problem  submitted  to  the  help  desk  which  is  referred  to  performance  management  for  resolution. 
Identifled  Components 

The  physical  and/or  logical  hardware  and  software  devices  (i.e.,  conq)uters,  networks,  and 
communication  elements)  of  a  DII/IS  configuration,  which  are  to  be  measured  and  analyzed  for 
efficient  and  effective  performance. 

Identified  Components  &  Metrics 

Hie  aggregate  of  identified  componeius  (e.g.,  i^ysical  an/or  logical  hardware  and  software),  and  the 
measurement  criteria  (i.e.,  metrics)  s^lied  to  the  components  for  purposes  of  analysis.  This 
information  is  used  to  identify  performance  targets  and  thresholds. 

Information/Reports 

Processed  CM  data  which  is  stored,  and  formatted  into  various  reports  made  available  for  use  by 
distribution. 

IT  Projections 

Data  and/or  forecasts  of  developments  in  technology  (e.g.,  hardware  design,  software  functionality, 
networking,  communications,  etc.)  that  may  provide  feasible  alternatives  to  satisfy  Information 
Technology  requirements. 

IT  Requirements 

Statement  of  functional  requirements  needed  to  satisfy  new  information  systems,  networking,  or 
communication.  Information  Technology  (T*)  requirements.  These  requirements  are  prepared  by  the 
Capacity  Planning  Function.  They  typically  specify  as  necessary  to  (1)  reduce  costs,  (2)  improve 
system  performance,  (3)  take  advantage  of  new  technology,  and  (4)  provide  new  technology  to  permit 
cost-effective  upgrades,  or  support  procurements  for  moving  towards  Open  Systems  Interconnection 
(OSI)  configurations.  These  requirements  are  shown  in  a  report  that  may  affect  several  functional 
areas  of  CM  activity. 

Measured  Performance 

Actual  system  measurements  for  a  specified  system  interval  recorded  in  a  performance  report. 
Measurement  Approach 

Procedures,  computer  performance  evaluation  methods,  and  criteria  used  for  measuring  and  analyzing 
system  performance.  This  could  include  a  determination  of  specific  tools  and  data  extraction  routines 
and  guidelines  needed  to  perform  these  measurements.  Identified  components,  metrics,  thresholds, 
and  targets. 
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Model  for  Validation 


A  newly  built  or  refined  model  of  a  DII/IS  environment  (e.g.,  workloads,  sy^lications,  hardware 
components,  system  components,  networks,  communications,  etc.)  that  is  presented  for  validation  by 
comparing  its  modeling  results  with  actual  performance  measurements. 

Modeling  Analysis  Approach 

Information  explaining  the  approach  to  take  and  the  CM  Data  and  CM  Models  required  for  proceeding 
with  a  modeling  effort.  The  modeling  methodology  is  determined  from  the  evaluation  of  a  request  for 
a  performance  modeling  analysis  study. 

Modeling  Request 

Requests  for  performance  modeling  analysis  studies  submitted  to  the  Capacity  Planning  staff  by  the 
performance  management  staff. 

Model  Results 

The  modeling  analysis  result(s)  obtained  after  conducting  a  series  of  iterative  modeling  "executions"  to 
evaluate  the  impacts  of  various  DII/IS  configuration  scenarios.  These  scenarios  may  include  such 
study  areas  as:  hardware  saturation,  configuration  change  options,  application  software  modifications, 
etc.  A  study  scenario  could  also  include  the  analysis  of  the  impact  of  a  projected  new  or  changed 
workload  on  a  current  baseline  DII/IS  environment.  The  model  results  show  how  the  performance  of 
a  specific  configuration  will  impaa  the  environment  being  modeled. 

Modeling  Shortfalls  and  Results 

Indicators  that  show  defects  in  the  performance  prediction  modeling  parameters  that  must  be  adjusted 
to  ensure  that  credible  results  are  obtained  from  the  Conduct  Performance  Prediction  Impact 
Analysis  Activity  (A415).  These  results  provide  feedback  information  on  the  shortfalls  encountered 
(e.g.,  incomplete  workload  specifications,  incompatible  metrics,  etc.),  and  adjustments  that  are  needed 
to  modify  prediction  parameters. 

Network/Communications  Capacity 

The  limits  on  transfer  speed  (bandwidth)  and  the  amount  of  information  that  can  flow  through  the 
logical  and  physical  network  communication  channels  (e.g.  how  many  devices  may  be  connected  in 
the  current  operating  environment  within  current  constraints,  and  maintain  effective  performance 
levels ' 

Network/Communications  Rqmts 

The  impaa  requirements  to  on-line  communications  network  interfaces  and  activities  as  they  affea  the 
system  environment  being  measured. 
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Non>validated  Model 


A  model  of  the  DU/IM  environment  or  an  application  whose  predicted  outcome  results  did  not  match 
actual  performance  measures.  It  must  either  be  modified  after  further  analysis  or  discarded. 

On-line  Computing/Communications  Rqmts 

The  type,  number,  and  connectivity  required  for  remote  terminals/communication  interfaces  connected 
to  information  system  resources  (e.g.,  mainframes,  networks,  communications  paths)  via  input/output 
channels,  ports,  and  hubs,  front-end  processors,  etc. 

Performance  Comparisons 

The  process  of  comparing  measured  performance  level  with  respective  target  performance  levels. 

This  process  identifies  acceptable  performance  levels,  as  well  as  conditions  of  unacceptable  (i.e.. 
Performance  Reports). 

Performance  Data 

Historical  performance  measurement  Hata  that  are  passed  to  the  CM  information/configuration  model 
database.  The  data  is  produced  in  the  Manage  Performance  Activity  (A3)  as  a  result  of  compartment 
or  system  evaluation  activities. 

Performance  Exceptions 

Performance  conditions  identified  as  not  acceptable  in  the  process  of  performance  comparison. 

Performance  Information 

A  collection  of  reports  generated  by  the  Manage  Performance  Activity  (A3).  Rqx>rts  include: 
Performance  Reports  and  Performance  Monitoring  Exceptions. 

Performance  Measurements/Target  Objectives 

(1)  Performance  Measurements 

Standard  measures  of  performance  (e.g.,  utilization,  response  time,  throughput,  millions  of 
instructions  per  second  (MIPS))  of  DII/IS  conqx)nents  that  are  available  for  use  in  a 
configuration. 

(2)  Target  Objectives 

Standard  measures  of  performance  (e.g.,  utilization,  response  time,  throughput,  millions  of 
instructions  per  second  (MIPS))  of  DII/IS  components  that  are  used  as  thresholds  for 
identifying  performance  levels. 


Performance  Monitoring  Data 

Performance  measurement  data  generated  by  system  .nonitoring  facilities  that  measures  the 
performance  of  hardware  component  utilization,  bandwidth,  DASD  response  time,  etc.  This  data  is 
the  foundation  for  DU/IS  con^nent  and  system  performance  evaluation  analysis. 

Performance  Monitoring  Exceptions 

Performance  measurement  data  generated  by  system  monitoring  facilities  that  measure  the  deviation  of 
component  and  system  performance  levels  from  established  performance  measurements/target 
objectives. 

Performance/Fault  Problem 

Problems  identified  which  adversely  impact  the  effectiveness  and  performance  of  the  DII  Information 
System  environment  (e.g.,  mainframe,  network,  or  communications).  These  problems  may  range 
from:  insufficient  memory,  insufficient  bandwidth  (capacity),  a  channel,  hub  or  port  imbalance,  or 
resource  utilization  that  exceeds  design  thresholds,  etc. 

Areas  addressed  include  fault  detection  and  monitoring,  error  detection  and  correction,  trouble 
shooting  performance  exceptions,  monitoring  alarms  and  problem  indicators,  and  taking  corrective 
actions.  These  problems  provide  the  basis  for  preparing  Performance  Problem  reports  for  the 
configuration,  operations,  performance,  and  security  fimctional  areas. 

Performance  Reports 

Computer  generated  reports,  describing  the  performance  of  an  operational  system  on  such  topics  as: 
CPU  utilization,  channel  utilization,  response  time,  fault  isolation,  alarm  detection,  network 
performance,  etc.  These  reports  are  used  by  the  accounting,  configuration,  operations,  performance, 
planning  and  security  functional  areas. 

Periodic  Reports 

Routine  reports  (daily,  weekly,  monthly,  aimually,  etc.)  provided  to  management  (e.g.,  data  center 
managers)  covering  such  things  as  data  center  performance  planning,  etc.  (e.g.,  a  daily  report 
detailing  performance  for  utilization  measurements  the  prior  day). 

Policy/Guidance,  Standards,  Planning,  Security,  Reporting  Rqmts  and  Quality  Controls 

Policies  and  guidance  governing  information  technology  practices  that  provide  direction  and  setting 
standards  for  operation  and  management  of  DoD  Data  Centers. 

Problem  Diagnosis 

The  results  of  data  collection  and  analysis  activities  that  provide  indicatior  *  of  possible  causes  for 
specific  problems.  The  diagnosis  (indicators)  may  require  further  evaluati  .;a,  including  trend 
analysis,  etc.,  to  further  isolate  problem  causes  and  provide  effective  solutions. 
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Project  Plans,  Project  Plan  Work  Assignments 


(1)  Project  Plans 

Formal  descriptions  of  actions  that  detail  the  tasks,  schedules,  milestones,  and  resources 
needed  to  perform  CM  Functions.  These  actions  can  include:  a  configuration  diange, 
performance  evaluation,  customer/CDA  requirements  analysis,  workload  forecasting, 
modifications  to  baseline  models,  etc. 

(2)  Project  Plan  Work  Assignments 

Formal  taskings  resulting  from  project  planning  analysis,  that  assign  work  to  designated  CM 
Functional  Activities. 

Projected  Costs 

Hardware  costs  associated  with  a  capacity  plan,  detailing  dollar  amounts  required  at  specific  dates 
within  a  planning  horizon. 

Recommendations 

The  results  of  CM  analysis  which  include: 

(1)  Performance  tuning  (e.g.,  changes  to  disk  data  set  placement,  CPU  workload  placement 
and  scheduling,  and  to  system  files,  etc.). 

(2)  Recommendations  to  acquire  (generate)  performance  measurements  which  are  currently 
not  available  but  required  for  performing  "end-to-end"  Performance  Analysis. 

(3)  Options  developed  by  the  Manage  Service  and  Plan  Capacity  activities  that  are  fed 
back  to  the  user  representatives  to  ensure  performance  complies  with  service  level 
agreements  or  can  satisfy  new  requirements. 

Recommended  Adjustments  to  Environment 

Any  adjustment  (to  software,  hardware,  or  system  parameters)  recommended  as  a  solution  to  a 
performance  problem.  These  adjustments  can  include  performance  tuning  recommendations  (e.g., 
workload  balancing,  data  set  placement,  operation  schooling,  modifications  of  bandwidth  capacity, 
etc.)  in  response  to  encountered  problems. 

Registered  Requests 

A  request  for  CM  services  (e.g.  CDA  requirements)  which  has  been  received  by  the  Manage  Service 
Activity(Al)  logged  into  the  projea  planning  system,  and  routed  to  the  appropriate  CM  Functional 
Area. 
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Registration  Status 

The  status  of  a  registered  customer  request  pertaining  to  task  completion  by  the  CM  Function. 
Reimbursable  Rates 

Rates  that  are  set  by  management  to  foster  recovery  of  costs  (i.e.,  fee-for-service)  associated  with 
providing  services  and  implications  processing  to  the  user  community.  These  are  standard  rates  that 
provide  reflections  of  the  "cost  of  doing  business",  and  are  therefore  useful  as  a  basis  for  estimating 
future  edacity  planning  costs  when  measured  against  projected  cost  estimates  of  resources  required. 

Request  for  CM  Services 

A  request  to  the  CM  Function  to  review,  analyze  and  act  upon  requests/requirements  from  customers. 
This  also  includes  problems/concems  from  the  IPC  help-desk. 

Request  for  CDA/CM  Data/Workload  Projections  and  Apjdications 

(1)  CDA/CM/DataAVorkload  Projections 

Request  for  application  oriented  capacity  planning  data  to  include  workload  intensity,  resource 
consunption  profiles,  and  performance  requirements,  etc. 

(2)  Applications  Data 

Information  needed  to  further  clarify  the  characteristics  of  the  operational  baseline. 

Request  for  Model  Change 

A  request  to  revise  or  create  a  baseline  configuration  model  because  the  current  baseline  model  does 
not  reflect  the  current  environment. 

Request  for  Retrieval  of  Performance  Data 

A  request  to  provide  specific  performance  data  extracted  from  the  CM  information/configuration 
model  database. 

Request  for  Support  (Financial,  Staffing,  Training,  Contracts,  etc.) 

Request  by  CM  management  for  support  in  ^  '^r  to  accomplish  the  CM  Function.  Areas  of  support 
include  financial,  staffing,  training,  travel,  .^ntractor  services,  hardware  and  software  tools,  etc. 

Request  to  Collect  Data 

A  request  to  acquire  additional  data  (e.g.,  performance,  planning,  workload  forecasts,  etc.)  that  must 
be  collected,  verified,  validated,  and  checked  for  completeness  in  order  to  be  useful  to  perform  the 
CM  Function. 
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Resource  Utilization  Cost 


Costs  associated  with  recovery  (e.g.  fee-for-service),  for  CM  services  and  operations,  as  well  as 
providing  financial  support  data  for  the  customer.  The  Resource  Utilization  Cost  report  is  provided 
for  the  accounting,  operations,  and  planning  functional  areas.  Costs  are  accumulated  on  the  utilization 
of  IS  resources.  These  costs  are  used  as  a  basis  for  cost  recovery.  (I.E.,  fee-for-service,  operations, 
as  well  as,  providing  financial  support  data  for  customer  billing,  and  IM  and  CM  management. 

Retrieved  Data 

Data  provided  from  the  CM  information/configuration  model  database. 

Rqmts  for  New  Metrics/Measures 

Requests  for  metrics/measures,  not  currently  available,  which  are  required  for  accurate  performance 
measurement  of  an  Information  System  Environment.  The  Requirements  for  New  Mctrics/Measure 
report  is  provided  for  the  operations,  performance,  and  planning  functional  areas. 

Security  Capacity  Utilization  Reports 

These  reports  are  produced  on  a  regular  basis  (e.g.,  weekly)  for  capacity  planning  and  performance 
measurement  activities.  The  reports  contain  information  that  show  various  performance  measures 
(e.g.,  I/O's,  percentage  of  memory  usage,  etc.)  concerning  the  impact  on  the  system  of  implementing 
security  software  programs  and  hardware  interfaces.  Through  these  reporting  data,  the  CM  Function 
can  derive  the  cost  (from  performance  data)  in  dollars  of;  (1)  the  cost  processing  of  capacity  usage, 
and  (2)  the  impact  security  measures  have  on  system  performance.  Reports  should  contain  appropriate 
levels  of  detail  to  illustrate  and  document  both  cost  and  performance  data.  Summarized  versions  of 
these  reports  should  be  provided  to  senior  management.  The  basis  for  these  reports  is  derived  from 
accounting  information  in  a  cost-recovery  system  that  displays  (security)  memory  utilization  as  an 
"application”,  which  is  interpreted  into  costing  data  through  a  cost-recovery  algorithm. 

Service  Alternatives 

Hardware  and/or  software  alternatives  to  service  the  requirements.  The  Service  Alternatives  report  is 
provided  to  the  operations  and  performance  functional  areas. 

SLA/SLO 

(1)  SLA  (Service  Level  Agreement) 

A  written  agreement  between  the  provider  of  services  and  some  element  of  the  user 
community  to  describe  and  document  user  services  required,  performance  expectations,  and 
responsibilities  which  are  agreed  upon  to  satisfy  customer  requirements.  The  parties  to  these 
agreements  normally  include  the  user  community,  CDA,  and  the  information  systems  center. 
These  agreements  describe  what  will  be  accomplished  along  with  the  schedule  and  priority  for 
producing  the  desired  result.  They  form  the  basis  for  establishing  service  level  objectives. 
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(2)  SLO  (Service  Level  Objective) 


Service  level  measurement  thresholds  against  established  performance  metrics  that  are  agreed 
upon  by  the  data  processing  function  staff  and  its  users  as  being  necessary  for  DII/IS 
components  and  systems. 

SLA/SLO  Feasibility 

A  determination  that  specific  SLO(s)  in  an  SLA  contain  meaningful  and  measurable  performance 
indicators.  Provides  the  SLA/SLO  Feasibility  report  for  the  accounting,  configuration,  performance, 
and  planning  fimctional  areas. 

SLA/SLO  Feasibility  Decision  Data 

The  results  of  analysis  performed  by  the  CM  Function  used  to  support  IM  management  decisions  in 
negotiating  SLA(s).  They  are  used  by  the  CM  Function  and  the  customer  to  make  decisions  on  the 
feasibility  of  measuring  and  achieving  the  SLO(s). 

Service  Level  Exceptions 

Incidents  detected  by  CM  performance  monitoring  where  information  system  performance  failed  to 
meet  established  service  level  objectives  (SLOs). 

Specialized  Performance  Analysis  Data 

The  results  of  performing  special  performance  measurements  that  are  used  to  support  detailed  and 
non-routine  performance  analysis  (e.g.,  trace  data,  program  execution  snapshots,  etc).  These  reports 
affect  areas  of  operations,  performance,  and  planning. 

Support  Rqmts  for  Maintaining  Configuration  Models 

Required  resources  (e.g.,  funding,  staffing,  training,  tools,  facilities,  etc.)  needed  by  the  CM  staff  to 
develop,  refine,  and  maintain  baseline  configuration  models. 

Support  Rqmts  for  Managing  System  Performance 

Required  resources  (e.g.,  funding,  staffing,  training,  tools,  facilities,  etc.)  needed  by  the  CM  staff  to 
measure,  monitor,  analyze,  evaluate,  optimize,  and  rqwrt  IS  performance. 

Support  Rqmts  for  Planning  Future  Capacity 

Required  resources  (e.g.,  funding,  staffing,  training,  tools,  facilities,  etc.)  needed  by  the  CM  staff  to 
analyze  capacity  requirements,  forecast  workload,  and  develop  edacity  plans. 
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Support  Rqmts  for  Providiog  Information 

Required  resources  (e.g..  iiinding,  staffing,  training,  tools,  facilities,  etc.)  needed  by  the  CM  staff  to 
acquire,  administer,  provide  data,  and  perform  routine  reporting. 

System  Security  Rqmts 

Requirements  for  installed  hardware/soitware  components  of  security  programs  that  must  be  used  to 
eliminate  or  minimize  (lAW  sqipropriate  security  levels)  the  risk  of  unauthorized  access  to  an  IS  or 
potential  for  malicious  maniptdations  of  data  files. 

A  well  managed  security  program  ensures  that  the  overhead  costs  of  security  implementations  can  be 
derived,  and  that  secure-systems  interfaces  effectively  provide  measures  of  the  impact  of  security 
measures  on  system  performance.  The  guidance  for  implementation  of  security  measures  are 
promulgated  by  a  variety  of  government  regulations,  and  cover  all  aspects  (PC  to  mainframe)  of  the 
Dn/IS  environment. 

Vendor  Pricing  &  Specifications 

(1)  Vender  Pricing 

Price  list  of  all  vendor  hardware/software  services  (purchased,  leased  and/or  maintained). 

This  data  is  used  to  provide  input  for  CM  cost  estimates. 

(2)  Vendor  Specifications 

Performance  specifications  of  all  vendor  hardware/software  products.  Specifications  can 
include:  performance  specifications,  tuning  measurements  and  practices,  system  management, 
propagation  delays,  maintenance  specifications,  operational  criteria,  etc. . 

Warfighter/Peacetime  Mission  Rqmts 

Interfaces  and  aq)acity  requirements  necessary  to  support  warfighting  missions.  Csqndty 
requirements  will  significantly  increase  peak  processing  loads  during  wartime  missions,  thus  reducing 
reserve  capacity. 

Worklmid  Projections 

The  result  of  analyses  and  modeling  activities  of  future  user  application  workload  projections  and 
associated  workload  resource  utilization  levels.  These  projections  assist  in  Plan  Capacity  Activity 
(A4)  analyses  to  predict  and  support  future  system/resource  requirements. 
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Appendix  D 
Entity  Definitions 


This  section  provides  detailed  definitions  for  the  principle  collection  of  dau  used  in  the  CM  Function 
data  models. 

APPLICATlON-FUNCnONAL-REQUIREMENT 

Data  contained  in  an  original  or  modified  Functional  Description  (FD),  prepared  by  the  functional 
activity  proponent,  which  describes  the  specifications  for  development  of  a  program  application.  (This 
also  includes  such  features  as  on-line  access). 

APPLICATION-PROCESSING-REQUIREMENT 

The  collection  of  data  describing  the  computing  requirements  (e.g.,  software  call  sequence,  program 
and  file  size,  and  security,  etc.)  identified  by  a  user  to  satisfy  the  application  functional  requirement. 
They  support  functional  requirements,  user  workloads,  access  requirements,  and  other  information 
services  requested. 

BASEUNE-MODEL 

A  representation  of  a  current  computing  and  communication  network  configuration,  to  include  the 
utilization  of  hardware  resources,  the  transaction  volumes  of  workloads  being  processed  and  the 
response  time,  and  throughput  of  the  workloads  used  as  the  starting  point  for  capacity  planning 
analysis. 

BENCHMARK 

A  specific  set  of  hardware/software  criteria,  programs,  and/or  system  architectures  using  a 
standardized  test  environment  and  standardized  performance  measurements  (e.g.,  a  computer  program 
which  executes  a  pre-determined  set  of  instructions  intended  to  represent  various  types  of  workloads 
such  as  batch,  on-line,  interactive,  etc.). 

CHANGE-REQUEST 

A  request  to  change  the  Defense  Information  Infrastructure/Information  Systems  (  DBAS)  baseline 
configuration  or  an  application  to  analyze  the  impact  on  performance  and  capacity  for  a  given  IS 
system  configuration.  These  changes  which  can  come  from  the  Information  Processing  Center  (IPC), 
vendors,  users.  Configuration  Control  Board  (CCB),  and  include:  changes  to  vendor  component 
specifications,  operating  systems,  performance  metrics,  etc. 

CHANNEL-CIRCUIT 

In  data  communications  a  means  of  2-way  communications  between  two  points,  consisting  of  transmit 
and  receive  channels. 
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COMMUNICATION-LINK  (MEDIA) 


The  physical  components  (e.g.,  twisted  pair,  optical  fiber,  coaxial  cable,  etc.)  through  which 
information  is  transmitted  and  that  is  used  to  provide  connectivity  within  and  between  networked 
components. 

COMPONENT 

Devices  or  collection  of  devices  comprising  a  DU/IS  architecture.  Examples  of  devices  include 
hardware,  software,  networks,  communications,  etc. 

END-SYSTEM-PRESENTATION-RQMT-(PRESENTATION-MEDIA) 

The  requirements  for  the  devices  used  for  the  presentation  of  information  (e.g.,  data,  imagery,  voice, 
radio,  etc.)  to  the  end  user.  Media  devices  may  be  of  a  variety  of  design  and  functionality  including; 
a  PC  screen,  optical  display,  stored  images,  video,  multi-media  display,  voice  capability,  etc. 

ENVIRONMENTAL-SUPPORT-SYSTEM 

The  executive  software  (e.g.,  operating  system,  transaction  processing  system,  etc.)  and  associated 
hardware  controlling  elements  that  provide  for  the  logical  management  of  a  computer  or 
coimnunications  network  system  in  the  execution  of  its  function.  This  also  includes  security 
interfaces,  memory  management,  system  supervisory  activities,  program  execution,  etc. 

FRONT-END 

In  a  Mainframe  Environment  a  communications  processor  that  connects  input/output  (I/O) 
communications  channels  on  one  end,  to  the  mainffame/host  on  the  other.  It  transmits  and  receives 
messages,  assembles  and  disassembles  packets,  and  detects  and  corrects  errors.  It  is  sometimes 
synonymous  with  a  communications  controller,  although  the  latter  is  usually  not  as  flexible. 

In  a  Network  Environment  the  communications  processor  that  provides  the  input/output  (I/O) 
mechanism  between  two  or  more  networked  devices  (e.g.,  client/server).  In  a  local  area  network, 
this  function  is  distributed  to  each  workstation  so  that  the  user  can  interact  with  other  networked 
devices. 

GATEWAY-ROUTER-BRIDGE 

Gateway 

In  distributed  computing  environments,  a  device  that  performs  protocol  conversions  between  two 
different  types  of  networks.  A  gateway  has  its  own  computer  processor  and  memory. 
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Router 


In  communications,  a  device  that  reads  the  destination  address  of  a  data  packet,  determines  the 
connect  path  for  transmission  according  to  internal  tables,  and  forwards  the  packet  to  a  station  on  a 
remote  network.  It  is  used  in  complex  networks  where  there  are  many  pathways  among  users. 

Bridge 

A  communications  device  that  is  used  to  transfer  data  between  two  networks  that  use  the  same 
communications  method  and  addressing  structure.  Some  bridges  -  known  as  "learning  bridges" 
contain  tables  that  contain  destination  address  of  stations  on  the  "local”  network;  otherwise,  packets 
are  passed  to  remote  networks. 

HUB-PORT-MODEM-SWITCH 

Hub 

A  central  switch  device  that  is  the  collection  point  for  a  number  of  (workstation)  lines  in  a  star 
topology.  Hubs  may  be  passive  or  "intelligent",  and  may  contain  electronics  which  can  boost  signal 
strength,  monitor  activity,  etc. 

Port 

A  path  (i.e.,  point  of  exit  or  entry)  that  may  connect  a  data  channel  to  a  front-end  processor  (FEP), 
serial  ports  connected  to  communications  lines  and  modems,  etc.  Serial  and  parallel  ports  on  personal 
computers  (PCs),  are  external  outlets  for  plugging  in  communications  lines,  r-.odems,  and  printers. 

Modem 

A  device  (  an  abbreviation  for  a  "modulator-demodulator  device)  that  adapts  a  computer  to  a  telephone 
line.  It  is  used  to  transmit  digital  signals  over  an  analog  transmission  system.  The  common  dial-up 
modem  speed  is  2400  bps.,  although  9600  bps  is  very  popular  too,  and  much  faster. 

Switch 

A  device  that  provides  a  physical  processor  and  the  digital  side  of  communication  facility.  In 
emerging  technology,  switching  hubs  may  be  used  to  implement  high-speed  packet  switching  in 
asynchronous  transfer  mode  (ATM),  Ethernet,  and  FDDI  networks. 

I/O-CHANNEL 

Input/output  (I/O)  high-speed  copper  wire  or  optical  fiber  pathways  between  the  central  processing 
unit  and  the  control  units  of  peripheral  devices,  DASD,  tape  drives,  servers,  etc. 

MAINFRAME/HOST 

The  classic  "glasshouse"  computer  environment,  consisting  of  one  or  more  medium-to-large  scale 
computers  capable  of  handling  several  thousand  on-line  terminals  or  workstations,  hundreds  of 
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megabytes  of  primary  storage,  and  hundreds  of  gigabytes  of  disk  storage  (secondary  storage).  This 
component  is  primarily  known  as  the  central  processing  unit  (CPU). 

MAINFRAME-OPERATING-SYSTEM 

The  operating  system  is  a  master  software  control  program  that  runs  the  coiiy)uter.  It  resides  in 
memory  at  all  times.  All  s^lication  programs,  communications  links,  etc.,  must  interface  with  the 
operating  system.  Also  known  as  the  system  "executive"  or  "supervisor",  it  performs  job  control 
management,  task  management,  data  management,  device  management  and  interfaces  with  the  security 
ftmction. 

MODELING-BENCHMARK-RESULT 

Measurements  that  provide  an  evaluation  or  comparison  of  performance  tests  of  information  systems 
and/or  application  programs  which  are  based  upon  specific  criteria  or  standards. 

NETWORK 

A  physical  and  logical  communications  infrastructure  that  facilitates  information  interchange  between 
systems  and  applications.  This  includes  the  physical  configuration  of  the  devices  and  the 
communications  media  that  connects  the  devices  (i.e.,  topology).  Network  architectures  typically 
conform  to  standards,  such  as  Ethernet,  Fiber  Distributed  Data  Interface  (FDDI),  Open  System 
Interconnection  (OSI),  etc.  Use  of  standards  can  ensure  interoperability  between  networks. 

Networks  are  typically  classified  by  size,  architectural  design,  and  geographical  scope.  Classifications 
include;  Local  Area  Networks  (LANs),  Backbones,  Wide  Area  Networks  (WANs),  and  Metropolitan 
Area  Networks  (MANs). 

PC-CLIENT-WORKSTATION-TERMINAL 

Any  terminal  or  personal  computer  or  access  device  that  provides  input  and  output  c^abilities 
between  a  host  and  a  user.  Some  workstations  can  run  one  program  at  a  time,  while  others  can  run 
more  than  one  at  a  time  (multi-tasking).  The  capability  of  the  workstation  is  based  on  its  memory 
size,  disk  capacity  and  processor  speed. 

PERFORMANCE-LOG-DATA 

Data  that  is  collected  by  the  systems  accounting  and  resource  management  monitoring  facilities  of  the 
computing  and  communications  networking  system  that  is  used  to  prepare  reports,  monitor 
performance  of  DII/IS  components  and  systems. 

PERFORMANCE-PREDICTION-DATA 

Performance  data  generated  by  a  configuration  model  showing  predicted  utilization,  service,  and 
performance  of  DII/IS  components  and  systems. 

PERIPHERAL 
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Any  hardware  device  connected  to  a  computer,  such  as  a  monitor,  keyboard,  printer,  plotter,  grai^cs 
tablet,  scanner,  joy  stick,  etc. 

PRIMARY-STORAGE 

The  computer's  workspace  where  all  operating  system,  program  execution,  and  data  processing  takes 
place  in  memory.  Operating  system  instructions,  program  instructions,  and  data  manipulation 
activities  all  occur  in  memory.  All  initialization  programs  are  permanently  resident  in  memory. 

PRIMARY-STORAGE  GNTERNAL  MEMORY) 

Primary-Storage  in  a  PC -Client-Workstation-Terminal 

PRIMARY-STORAGE  (MAIN  MEMORY) 

Primary-Storage  in  a  Mainframe/Host. 

PROTOCOL 

A  strictly  defined  procedure  and  message  format  that  allows  two  or  more  systems  to  communicate 
over  a  physical  transmission  medium.  Each  layer  of  a  protocol  performs  a  specific  function,  such  as 
routing,  end-to-end  reliability,  and  connectivity.  "Local  Area  Networking,”  Matthew  G.  Naugle. 
McGraw-Hill,  1991. 

SECONDARY-STORAGE 

Devices  used  to  store,  manipulate,  and  retrieve  data  (e.g.,  magnetic  disk,  magnetic  tape,  optical  disk, 
etc).  In  client/server  architectures  a  server  is  often  used  as  a  disk  drive  for  access  to  files,  etc. 

SECONDARY-STORAGE  DASD  &  TAPE) 

Secondary-Storage  in  a  Mainframe/Host. 

SECONDARY-STORAGE  (WORKSTATION  HARD  DISK) 

A  Secondary-Storage  area  resident  in  a  PC-Client- Workstation-Terminal. 

SECURITY-SYSTEM-INFRASTRUCTURE 

The  installed  hardware/sofitware  components  and  infrastructure  for  security  programs  that  must  be 
us.d  to  eliminate  or  minimize  (lAW  appropriate  security  levels)  the  risk  of  unauthorized  access  to  an 
IS  or  potential  for  malicious  manipulations  of  data  files. 

A  well  managed  security  program  ensures  that  the  overhead  costs  of  security  implementations  can  be 
de'  ed,  and  that  secure  systems  interfaces  effectively  provide  measures  of  the  impact  of  security 
me-^ures  on  system  performance.  The  guidance  for  implementation  of  security  measures  are 
promulgated  by  a  variety  of  government  regulations,  and  cover  all  aspects  (PC  to  mainframe)  of  the 
Dli/IS  environment. 
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SERVER 


A  computing  device  (usually  not  associated  with  a  mainframe  environment)  that  is  a  combination  of 
hardware  and  software  used  to  provide  specific  services  to  other  devices  (clients)  in  a  shared 
networked  environment.  Services  may  include:  E-mail,  file  storage,  communications,  etc.  These 
devices  can  be  used  as:  File  Servers,  Mail  Servers,  Print  Servers,  Communication  Servers,  etc. 

STANDARD-PERFORMANCE-METRIC-SLO 

Standard  measures  used  to  assess  the  performance  (e.g.,  utilization,  response  time,  throughput,  million 
of  instructions  per  second  (MIPS),  etc.)  of  a  component.  The  results  can  be  used  to  evaluate  system 
performance  against  achievement  of  service-level  objectives  (SLO). 

SYSTEM-EXECUTION-ENVIRONMENT 

A  computer  and/or  communications  network  system  configuration  and  its  components  that  comprise 
the  execution  environment.  It  is  used  to  execute  the  required  workload,  provide  on-line  access  paths 
between  users  and  their  applications/databases,  and  process  program  implications. 

USER-WORKLOAD-SCENARIO 

The  data  necessary  to  identify  user  workload  requirements  in  terms  relevant  to  the  CM  Function,  and 
in  turn,  produce  a  model  of  the  user's  workload.  The  data  includes  such  things  as  number  of 
transactions,  peak  processing  periods,  number  of  users  (total  and  concurrent),  and  number  of  terminals 
to  be  connect^  to  the  system,  etc. 

WORKLOAD-CHARACTERIZATION 

The  specification  of  the  user  application  workload  to  be  processed  on  a  computing  environment  in 
terms  of  amount  of  data  to  be  processed,  type  of  data,  frequency  of  processing,  mix  of  applications 
during  a  selected  time  period,  amount  of  memory  and  resources  required,  etc.  [The  specification  also 
includes  such  things  as  number  of  transactions,  peak  processing  periods,  number  of  users  (total  and 
concurrent),  and  number  of  terminals  to  be  connected  to  the  system,  etc.] 
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Appendix  E 
Terms 

Capacity  Management 


These  terms  rq)resent  specific  technical  and  organiz^onal  terminology  used  in  this  report.  The  terms 
may  have  different  meanings  outside  the  Caf>acity  Management  (CM)  context. 

Backbone 

A  communication  path  that  is  used  to  connect  multiple  networks  together.  An  example  is  a  fiber  optic 
cable  using  FDDI  technology  within  a  building. 

Base>level 

(1)  A  military  installation  that  has  Information  Systems  that  operate  under  local  management  and 
control. 

(2)  Not  part  of  a  Megacenter's  logical  or  physical  computer  configuration. 

Capacity 

The  capability  (as  defined  by  a  vendor  or  standard)  of  a  computer  or  system  to  deliver  acceptable 
levels  of  service  to  satisfy  user  workloads  and  service-level  objectives.  Capacity  is  generally 
measured  in  terms  such  as:  MIPS,  bandwidth,  bytes,  transactions  and  I/O  processing,  workload 
volume,  etc.  Categories  include  reserve,  available,  and  planned  capacity. 

Capacity  Management 

A  structured  framework  for  managing  Information  Systems,  Networks,  and  Communications  resources 
(PC-to-Mainffame).  The  Capacity  Management  (CM)  Function  is  comprised  of  five  primary  activities: 
Manage  Service,  Provide  Information,  Manage  Performance,  Plan  C^ncity,  and  Maintain  Capacity 
Management  Models.  The  CM  Function  provides  a  structured  framework  for  managing  the 
performance  of  Information  Systems,  network,  and  communications  resources  (PC-to-Mainffame)  to 
ensure  that:  (1)  resources  are  sufficient  and  available  to  meet  defined  user  service-level  objectives  and 
capacity  requirements,  (2)  resource  utilization  is  cost-efficient,  effective,  and  well-managed,  (3) 
performance  is  monitored,  measured,  and  evaluated  to  ensure  maintenance  of  required  performance 
levels,  and  (4)  workload  forecasts  are  made,  reserve  capacity  is  available,  and  all  security 
requirements  are  met. 

Central  Design  Activity  (CDA) 

The  activity  within  the  DoD  that  translates  user  requirements  into  design  requirements  and  plication 
code  for  subsequent  processing  and  inclusion  in  DII/IS  environments. 
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Client  Server  Architecture 


The  architecture  in  which  the  client  is  the  requesting  machine  (PC  or  workstation)  and  the  server  is 
the  supplying  machine  (LAN  file  server,  mini  or  mainframe).  The  client  provides  the  user  interface 
and  performs  some  or  most  of  the  application  processing.  The  server  maintains  the  databases  and 
processes  requests  from  the  client  to  extract  data  from  or  update  the  database.  The  server  also 
controls  the  application's  integrity  and  security.  ’The  Computer  Glossary,"  Alan  Freedman. 
AMACOM,  1993. 

CM  Information/Configuration  Model  Database 

A  database  (either  on  DASD  or  magnetic  tape)  wtere  all  CM  collected  and  retrieved  data,  and  all 
benchmarks  and  configuration  data/models  are  kept  for  future  reporting  requirements  or  modeling 
efforts. 

Configuration  Control  Board  (CCB) 

A  board  composed  of  technical  and  management  representatives  who  recommend  approval  or 
disapproval  of  proposed  changes  to  the  DII/IS  baseline  configuration.  The  board  also  recommends 
approval  or  disapproval  of  proposed  waivers  and  deviations  from  a  Dn/IS  current  proved  baseline 
documentation. 

Contention 

The  competition  for  available  resources.  Contention  arises  when  two  or  more  devices  attempt  to  use  a 
single  resource  at  the  same  time. 

Cost-Recovery 

A  Fee-For-Service  approach  of  receiving  payment  for  services  provided,  in  which  customers  of  an 
information  system  environment  are  charges  for  their  use  (consumption)  of  resources  and  services. 

The  charge  for  this  service  is  based  on  the  rates  that  attribute  costs  for  defined  levels  of  usage.  A 
cost-recovery  (charging)  system  consists  of  two  major  components:  "rate-setting"  and  "billing",  (see 
also;  "Fee-For-Service".) 

Data  Loss 

The  occurrence  of  partial  or  incomplete  transmission  of  data  from  one  device  to  another. 

Error  Rates 

A  measure  of  the  effectiveness  of  a  communications  channel.  It  is  the  ratio  of  the  number  of 
erroneous  units  of  data  to  the  total  number  of  units  of  data  transmitted. 

Fee-For-Service 

A  method  of  gaining  reimbursement  for  services  provided  by  charging  customers  (e.g.,  of  an 
information  system)  for  the  use  or  consumption  of  services  or  resources.  (See  also:  "Cost-Recovery") 
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Information  Processing  Center  (IPC) 


(1)  One  of  the  various  terms  used  to  define  a  place  (e.g.,  building)  where  large  conqiuter  systems  are 
located.  IPC's  may  also  function  as  a  data  processing  center  (DPC),  information  technology  faciUty 
(TTF),  data  processsing  installation  (DPI),  information  systems  center  GSC),  conqiuter  center,  or  data 
center. 

(2)  An  organizational  grouping  set  of  personnel,  hardware,  software,  and  physical  facilities,  whose 
primary  function  of  which  is  the  operation  of  information  systems,  and  providing  services,  to  a  user 
community. 

(3)  A  logical  or  physical  collection  of  IPC's,  which  may  also  include  communications  and  network 
topologies  and  systems  that  the  DoD  has  described  as  a  "megacenter".  (See  also:  "Megacenter") 

Information  Technology  (IT) 

The  hardware  and  software  used  in  connection  with  Government  information,  regardless  of  the 
technology  involved,  (e.g.,  computers,  telecommunications,  micrographic,  etc). 

Megacenter 

One  of  (currently  16)  a  number  of  planned  large  DoD  IPC's  that  will  provide  all  the  information 
systems,  communications  and  networking  services  for  the  DoD's  computer  processing 
requirements/needs . 

Propagation  Delay 

The  time  it  takes  for  a  transaction  or  packet  to  be  processed  and  forwarded  by  a  single  device. 
Regional  Processing  Center  (RPC) 

A  consolidated  computer  installation  and  its  supporting  organization  that  provides  computer 
processing,  data  storage,  data  communication,  computer  liaison  support  and  other  related  services  to 
users. 

Response  Time 

The  time  interval  between  a  request  and  a  reply  from  a  client/workstation  and  a  host/server.  In  data 
communications,  response  time  includes  transmission  time  to  the  con^uter,  processing  time  at  the  . 
computer,  and  transmission  time  back  to  the  originating  device. 
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Security 


The  area  dealing  with  all  the  aspects  of  defining  security  practices,  and  methods  of  in^lementing 
security  controls,  to  ensure  that  appropriate  levels  of  security  are  maintained.  This  includes 
management  practices,  providing  hardware  and  software  capabilities  ,  protocols  (e.g.,  Sinq)le  Network 
Management  Protocol  (SNMP  2),  etc.,  that  will  enable  system  controls,  limit  access,  and  prevent 
unauthorized  use  or  manipulation  of  communications  and  networking  environments. Specific  types  of 
information  to  be  communicated,  normally  classified  as  one  of  the  following;  voice,  video,  imagery, 
or  data. 

Throughput 

The  number  of  transactions  or  jobs  processed  by  a  computing  or  communications/network  component 
per  unit  of  time. 

Utilization 

The  performance  characteristics  that  indicate  the  level  of  usage  of  a  component  or  system.  It  is  a 
measure  of  the  amount  of  time  a  component  or  system  is  actively  used  to  the  total  amount  of  time  it  is 
available.  Excessive  levels  of  utilization  may  impact  the  speed  with  which  work  is  processed,  as  well 
as  cause  contention  between  components. 

Workload 

The  characterization  of  work  to  be  processed  on  a  computer  or  network  component.  This  includes 
transaction  volumes,  type,  frequency,  resource  utilization  requirements,  etc.  The  size  and 
characteristics  of  specific  workloads  impact  the  performance  and  utilization  of  a  system  and 
components. 
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Terms 

Corporate  Information  Management 
Functional  Process  Improvement 


These  terms  are  the  specific  references  to  Corporate  Information  Management  (CIM)  terminology  used 
in  this  report. 

Activity  Based  Costing  (ABC) 

An  accounting  technique  that  allows  an  enterprise  to  determine  the  actual  costs  associated  with  each 
product  and  service  produced  by  that  enterprise  without  regard  to  the  organizational  structure  of  the 
enterprise. 

Activity  Model 

A  gr^hic  representation  of  a  business  process  that  exhibits  the  activities  that  make  up  the  business 
process  to  any  desired  level  of  detail.  An  activity  model  reveals  the  interactions  between  activities  in 
terms  of  inputs  and  outputs  while  showing  the  controls  placed  on  each  activity  and  the  types  of 
resources  assigned  to  e^  activity. 

AS-IS  Model 

A  model  that  represents  the  current  state  of  the  organization  modeled,  without  any  specific 
improvements  included. 

Business  Process  Improvement  Program  (BPIP) 

The  application  of  one  or  more  related  business  processes  enabling  an  enterprise  to  inq)rove  the  value 
of  its  products  and  services  while  reducing  resource  requirements.  The  results  of  a  successful  BPIP 
are  productivity  and  quality  improvements.  A  business  case  or  action  plan  is  a  required  deliverable 
for  all  BPIP  actions.  A  BPIP  may  or  may  not  include  Business  Process  Redesign  actions. 

Business  Process  Redesign 

The  action  of  analyzing  AS-IS  activity  and  rule  models  with  the  intent  to  construct  a  TO-BE  activity 
and  rule  model  that  will  yield  potential  in^)rovements  in  the  performance  of  the  business  process. 

Context  Diagram 

Represents  a  single  activity  of  the  subject  being  modeled. 

Corporate  Information  Management  (CIM) 

A  DoD  program  designed  to  reduce  costs  and  increase  effectiveness  through  analysis  of  business 
processes.  The  main  focus  of  the  initiative  is  on  management  methods,  and  its  primary  objective  is 
business  process  improvement. 
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Data  Model  (Business  Rule  Model) 


A  graphical  representation  of  an  organization's  information  and  data  assets  expressed  in  terms  of 
entities  and  relationships.  Relationships  are  also  called  business  rules  because  they  enable  or  constrain 
business  actions.  Data  models,  like  activity  models,  have  As-Is  and  To-Be  rq)resentations. 

Decomposition  Diagram 

A  more  detailed,  lower  level  diagram  representing  the  insides  of  the  parent  activity  box. 

Entity  Relationship  Model 

The  result  of  applying  the  business  rule/data  modeling  technique.  It  is  a  graphic  or  structured 
narrative  representation  of  the  data  meanings  and  business  rules  in  an  organization. 

Functional  Economic  Analysis  (FEA) 

A  methodology  for  analyzing  and  evaluating  alternative  business  process  changes  and/or  information 
system  investments  and  management  practices.  Within  DoD,  FEA  is  a  business  case. 

ICOM  -  Inputs,  Controls,  Outputs,  Mechanisms 

The  acronym  for  the  roles  for  data  or  material  on  an  activity  model.  ICOMs  are  represented  by 
arrows  that  interconnect  activity  boxes.  They  are  named  using  a  noun  or  noun  phrase. 

Input  -  Data  or  material  used  to  produce  an  output  of  an  activity. 

Control  •  Data  that  constrain  or  regulate  the  activity.  Controls  regulate  the  transformation  of 
inputs  into  outputs. 

Output  -  Data  or  materials  produced  by  or  resulting  from  the  activity.  It  must  include  the 
input  data  in  some  form. 

Mechanism  -  Usually  people,  machines,  or  existing  systems  that  provide  energy  to,  or 
perform  the  activity. 

IDEF  -  Integrated  Definition  Language 

A  modeling  technique  designed  to  capture  the  processes  and  structure  of  information  in  an 
organization. 

IDEFO 

An  activity,  or  behavior,  modeling  technique. 
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IDEFIX 


A  rule,  or  data,  modeUng  technique. 

Nodie  Tree 

A  node  tree  is  a  type  of  activity  diagram.  An  activity  and  its  deconqmsitions  are  displayed  in  a 
hierarchial  manner.  No  ICOMs  are  shown  on  a  node  tree.  Since  activity  diagrams  and  their 
decompositions  are  rq)resented  on  many  pages  in  a  model,  a  node  tree  can  be  used  to  overview  a 
model.  They  are  also  useful  for  trying  out  different  decomposition  strategies  before  drafting  activity 
diagrams. 

Non-value  Added  Activity 

Work  performed  in  connection  with  the  production  of  a  desired  product  or  service  for  which  a 
customer  is  not  willing  to  pay. 

TO-BE  Model 

Models  that  are  the  result  of  applying  improvement  opportunities  (from  the  Baseline  modeling  effort) 
to  the  current  (AS-IS)  business  environment.  These  TO-BE  models  rq)resent  how  future  and 
improved  processes  should  occur. 

Value  Added  Activity 

Work  performed  in  connection  with  the  production  of  a  desired  product  or  service,  for  which  a 
customer  is  explicitly  or  implicitly  willing  to  pay. 
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Appendix  F 
Acronyms 


AFB 

Air  Force  Base 

ATM 

Asynchronous  Transfer  Mode 

bps 

bits  per  second 

C3I 

Command,  Control,  Communications,  &  Intelligence 

CCB 

Configuration  Control  Board 

CDA 

Central  Design  Activity 

CIM 

Corporate  Information  Management 

CM 

Capacity  Manage  :tent 

CONUS 

Continental  United  States 

CPU 

Central  Processing  Unit 

DASD 

Direct  Access  Storage  Device 

DASD  (IM) 

Deputy  Assistant  Secretary  of  Defense/Information  Management 

DASD  aS) 

Deputy  Assistant  Secretary  of  Defense/Information  Systems  (Now  DASD/IM) 

DASD  (P&R)  ITR 

D^ty  Assistant  Secretary  of  Defense  (Plans  and  Re^urces),  Information 
Te^ology  Resources 

Dn 

Defense  Information  Infrastructure 

DU/IS 

Defense  Information  Inffastructure/Information  Systems 

DISA 

Defense  Information  Systems  Agency 

DISA/JIEO/CIM 

Defense  Information  Systems  Agency/Joint  Interoperability  &  Engineering 
Organization/Center  for  Information  Management 

DISN 

Defense  Information  Systems  Network 

DISO 

Defense  Information  S^ces  Organization 

Drrso 

Defense  Information  Technology  Services  Organizations  (now  DISO) 

DLA 

Defense  Logistics  Agency 

DMRD 

Defense  Management  Report  Decision 

DoD 

Department  of  Defense 

FDDI 

Fiber  Distributed  Data  Interface 

FD 

Functional  Description 

lAW 

In  Accordance  With 

IM 

Information  Management 

I/O 

Input/Output 

IPC 

Information  Processing  Center 

IRM 

Information  Resource  Management 

IS 

Information  Systems 

IT 

Information  Technology 

LAN 

Local  Area  Network 

MAJCOM 

Major  Command 

MAN 

Metropolitan  Area  Network 

MB 

MEGABYTE 

Mbps 

Megabits  per  second 

MIPS 

Millions  of  Instructions  Per  Second 

MTBF 

Meantime  Between  Failures 

OSD 

Office  of  the  Secretary  of  Defense 
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OSI 

Open  Systems  Interconnection 

RMF 

Resource  Measurement  Facility 

RPC 

Regional  Processing  Center 

SLA 

Service  Level  Agreement 

SLO 

Service  Level  Objective 

SMF 

Systems  Management  Facility 

SNA 

Systems  Network  Architecture 

SONET 

Synchronous  Optical  Network 

TCP/IP 

Transmission  Control  Protocol/lntemet  Protocol 

WAN 

Wide  Area  Network 
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Acronyms 

Corporate  Information  Management 
Functional  Process  Improvement 


ABA 

Activity  Based  Analysis 

ABC 

Activity  Based  Costing 

BPI 

Business  Process  Improvement 

BPIP 

Business  Process  Improvement  Program 

CIM 

Corporate  Information  Management 

ERD 

Entity  Relationship  Diagram 

FEA 

Functional  Economic  Analysis 

FPl 

Functional  Process  Improvement 

FPIP 

Functional  Process  Improvement  Program  (DoD  8020. 1-M) 

ICOM 

Input,  Control,  Output,  Mechanism;  Roles  for  data  or  material  on  an  activity 

IDEF 

integrated  Definition  Languages 

IDEFO 

IDEF  Activity  Modeling  Technique 

IDEFIX 

IDEF  Data/Business  Rule  Modeling  Technique 
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Appendix  G 

Defense  Information  Infrastructure  (DII) 

Concept 


Defense  Information  Infrastructure 
Objective  Architecture  Overview-1 998 


Concept 

1  February  1998 
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